From nobody Wed Dec 2 12:10:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605D03A1546 for ; Wed, 2 Dec 2020 12:10:18 -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 Sy47cthFXpzf for ; Wed, 2 Dec 2020 12:10: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 D62DE3A1476 for ; Wed, 2 Dec 2020 12:10:14 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B2KACfZ020140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 2 Dec 2020 15:10:13 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_387E206F-815D-4192-A05B-E851E8AE906A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 2 Dec 2020 15:10:12 -0500 References: To: GNAP Mailing List In-Reply-To: Message-Id: <7FA6D477-1D34-4267-902E-D6C3218211C1@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 02 Dec 2020 20:10:18 -0000 --Apple-Mail=_387E206F-815D-4192-A05B-E851E8AE906A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The editors met again today to process some more of the outstanding = issues. The following issues have been added to the queue for pending = close with the same Dec 11th deadline as the first set (that=E2=80=99s = next Friday). Editors=E2=80=99 comments are included on GitHub. Pending Close: * JWS Headers for JOSE-based signature methods ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/106 * Key redundancy in DPoP method ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/111 * Fragility of JOSE-based signature methods ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/108 * Detached-JWS Header,=20 ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/107 * Create more examples of interaction modes ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/52 * Splitting the =E2=80=9Cclaims=E2=80=9D request ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/63 * Response Extensions ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/80 * Provide guidance for defining new interactions ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/61 * Guidance for Grant Request Extensions ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/65 * Privacy considerations of returned user information ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/74 * Alignment with RAR ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/34 * Non-role protocol elements ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/33 Needs Text: * Updating and reading access tokens ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/99 The editors believe that this list list now includes all of the issues = filed that represent items that are mostly just comments on the state or = history of the protocol as extracted from Editor=E2=80=99s Notes, as = discussed in #128. https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/128 The goal of this exercise, as stated in #128, is to clean out the = clutter of the issue backlog and allow us to focus on specification = text, issues, and features. Note that for these marked issues, closing = the issue is not an indication that a final decision has been made to = exclude a feature or option. However the editors determined that the = issues as written did not incorporate actionable text or sufficient use = cases to move forward at this time. If future discussions wish to raise = any of these issues again, particularly additional features, they can do = so with more explicit context and a concrete way forward, and link back = to these historical items. Additionally, several of these were determined to be part of larger = discussions, and so separate issues have been raised to incorporate = them: * Terminology ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 * Security considerations ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/135 * Guidance for extensions ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/134 * Privacy considerations ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 * Claim extensions ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 Note that other issues are also being processed in addition to this = clean-up effort, so please keep an eye out for pull requests and = discussions on those. Also please note that if you :support: a change in = a pull request, it=E2=80=99s helpful to the group if you comment as = such, or leave an =E2=80=9Capproved=E2=80=9D review using the GitHub = issue tracker. Finally, the editors are working on a proposed update to the use of the = =E2=80=9Cproposed=E2=80=9D tag based on working group feedback, and = we=E2=80=99ll update shortly with those details. Thank you, =E2=80=94 Justin, Aaron, and Fabien > On Nov 25, 2020, at 11:36 AM, Aaron Parecki wrote: >=20 > The editors met yesterday to discuss the issues that were pulled out = of the previous draft text and document a process for how to resolve = these and future issues. We would like to explain how we plan on using = labels on GitHub issues to keep track of discussions and keep things = moving. >=20 > When there are substantive issues or pull requests, the editors will = avoid merging or closing those outright, and instead mark them as = "pending", so that these can be brought to the attention of the larger = group. If no additional discussion happens on these, the merge or close = action will be taken in 7 days. Note for this first round we are setting = the deadline for the issues below as Dec 11th due to the US holiday and = the fact that this is the first time using this process. >=20 > "Pending Merge" > When specific text is proposed in a PR (by anyone, not limited to the = editors), and the editors believe this text reflects the consensus of = the working group, this marks that the PR will be merged in 7 days = unless there is a clear alternative proposal accepted by the working = group. >=20 > "Pending Close" > When the editors believe an issue no longer needs discussion, we'll = mark it "Pending Close". The issue will be closed in 7 days unless = someone brings new information to the discussion. This tag is not = applied to issues that will be closed by a specific pull request. >=20 > There are two additional labels we will use to flag issues to the = group. >=20 > "Needs Text" > The editors suggest this issue needs additional text in the spec to = clarify why this section is needed and under what circumstances. Without = a concrete proposal of text to be included in the spec, this section = will be removed in a future update. >=20 > "Postponed" > This issue can be reconsidered in the future with a more concrete = discussion but is not targeted for immediate concrete changes to the = spec text. When used on its own, this label does not indicate that an = issue is targeted to be closed. An issue may also be marked "Pending = Close", and this is used so that we can distinguish closed issues = between discussions that have concluded or things that we may want to = revisit in the future. Remember that closed issues are not deleted and = their contents are still findable and readable, and that new issues can = reference closed issues. >=20 > With these labels in mind, here are the list of issues and their = statuses we were able to discuss on our last editor's call. The action = on these pending issues will be taken on Dec 11th to give the group = enough time to review this list. For this first round, many of the = issues are marked "Pending Close" as we're looking for low hanging fruit = to prune the list of issues down. In the future, you can expect to see = more "Pending Merge" issues as we're bringing proposed text to review by = the WG. >=20 > Postponed: >=20 > * Generic claim extension mechanism > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 = >=20 > Pending Merge: >=20 > * Make access token mandatory for continuation API calls > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 = >=20 > Postponed and Pending Close: >=20 > * Fetchable Keys > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 = > * Including OpenID Connect Claims > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 = > * Application communication with back-end > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 = > * Additional post-interaction protocols > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 = >=20 > Pending Close: > =20 > * HTTP PUT vs POST for rotating access tokens > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 = > * Use of hash with unique callback URL > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 = > * Interaction considerations > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 = > * Expanding dynamic reference handles > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 = > * Post interaction callback nonce > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 = > * Unique callback URIs=20 > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 = > * Instance identifier > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 = > * Requesting resources by reference > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 = > * Mapping resource references > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 = >=20 > --- > Aaron Parecki > https://aaronparecki.com >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_387E206F-815D-4192-A05B-E851E8AE906A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = editors met again today to process some more of the outstanding issues. = The following issues have been added to the queue for pending close with = the same Dec 11th deadline as the first set (that=E2=80=99s next = Friday). Editors=E2=80=99 comments are included on GitHub.

Pending Close:

* JWS Headers for = JOSE-based signature methods
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/106
* Key redundancy in DPoP method
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/111
* Fragility of JOSE-based signature = methods
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/108
* Detached-JWS Header, 
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/107
* Create more examples of interaction = modes
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/52
* Splitting the =E2=80=9Cclaims=E2=80=9D = request
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/63
* Response Extensions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/80
* Provide guidance for defining new = interactions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/61
* Guidance for Grant Request Extensions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/65
* Privacy considerations of returned user = information
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/74
* Alignment with RAR
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/34
* Non-role protocol elements
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/33

Needs = Text:
* Updating and reading access = tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/99

The editors = believe that this list list now includes all of the issues filed that = represent items that are mostly just comments on the state or history of = the protocol as extracted from Editor=E2=80=99s Notes, as discussed in = #128.

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

The goal of = this exercise, as stated in #128, is to clean out the clutter of the = issue backlog and allow us to focus on specification text, issues, and = features. Note that for these marked issues, closing the issue is not an = indication that a final decision has been made to exclude a feature or = option. However the editors determined that the issues as written did = not incorporate actionable text or sufficient use cases to move forward = at this time. If future discussions wish to raise any of these issues = again, particularly additional features, they can do so with more = explicit context and a concrete way forward, and link back to these = historical items.

Additionally, several of these were determined to be part of = larger discussions, and so separate issues have been raised to = incorporate them:

* Terminology
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29
* Security considerations
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/135
* Guidance for extensions
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/134
* Privacy considerations
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133
* Claim extensions
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131

Note that = other issues are also being processed in addition to this clean-up = effort, so please keep an eye out for pull requests and discussions on = those. Also please note that if you :support: a change in a pull = request, it=E2=80=99s helpful to the group if you comment as such, or = leave an =E2=80=9Capproved=E2=80=9D review using the GitHub issue = tracker.

Finally, the editors are working on a proposed update to the = use of the =E2=80=9Cproposed=E2=80=9D tag based on working group = feedback, and we=E2=80=99ll update shortly with those details.

Thank you,
 =E2=80=94 Justin, Aaron, and Fabien

On Nov 25, 2020, at 11:36 AM, Aaron Parecki <aaron@parecki.com> = wrote:

The editors met yesterday to = discuss the issues that were pulled out of the previous draft text and = document a process for how to resolve these and future issues. We would = like to explain how we plan on using labels on GitHub issues to keep = track of discussions and keep things moving.

When there are substantive issues or pull requests, the = editors will avoid merging or closing those outright, and instead mark = them as "pending", so that these can be brought to the attention of the = larger group. If no additional discussion happens on these, the merge or = close action will be taken in 7 days. Note for this first round we are = setting the deadline for the issues below as Dec 11th due to the US = holiday and the fact that this is the first time using this process.

"Pending Merge"
When specific = text is proposed in a PR (by anyone, not limited to the editors), and = the editors believe this text reflects the consensus of the working = group, this marks that the PR will be merged in 7 days unless there is a = clear alternative proposal accepted by the working group.

"Pending Close"
When the editors = believe an issue no longer needs discussion, we'll mark it "Pending = Close". The issue will be closed in 7 days unless someone brings new = information to the discussion. This tag is not applied to issues that = will be closed by a specific pull request.

There are two additional labels we will use to flag issues to = the group.

"Needs Text"
The = editors suggest this issue needs additional text in the spec to clarify = why this section is needed and under what circumstances. Without a = concrete proposal of text to be included in the spec, this section will = be removed in a future update.

"Postponed"This issue can be reconsidered in the future with a more = concrete discussion but is not targeted for immediate concrete changes = to the spec text. When used on its own, this label does not indicate = that an issue is targeted to be closed. An issue may also be marked = "Pending Close", and this is used so that we can distinguish closed = issues between discussions that have concluded or things that we may = want to revisit in the future. Remember that closed issues are not = deleted and their contents are still findable and readable, and that new = issues can reference closed issues.

With = these labels in mind, here are the list of issues and their statuses we = were able to discuss on our last editor's call. The action on these = pending issues will be taken on Dec 11th to give the group enough time = to review this list. For this first round, many of the issues are marked = "Pending Close" as we're looking for low hanging fruit to prune the list = of issues down. In the future, you can expect to see more "Pending = Merge" issues as we're bringing proposed text to review by the WG.

Postponed:

* = Generic claim extension mechanism
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131

Pending Merge:

* Make access token mandatory for continuation API calls
** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129=

Postponed and Pending Close:

* Fetchable Keys
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Including OpenID Connect Claims
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64
* Application communication with back-end
**= https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
* Additional post-interaction protocols
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83

Pending Close:
  =  
* HTTP PUT vs POST for rotating access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100
* Use of hash with unique callback URL
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84
* Interaction considerations
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
* Expanding dynamic reference handles
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76
* Post interaction callback nonce
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73
* Unique callback URIs
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
* Instance identifier
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46
* Requesting resources by reference
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
* Mapping resource references
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35

---
Aaron Parecki
https://aaronparecki.com

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

= --Apple-Mail=_387E206F-815D-4192-A05B-E851E8AE906A-- From nobody Thu Dec 3 14:14:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBD33A0D74 for ; Thu, 3 Dec 2020 14:14:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DYxZ7-l91BwQ for ; Thu, 3 Dec 2020 14:14:39 -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 C4CB03A0D73 for ; Thu, 3 Dec 2020 14:14:39 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id o8so3775600ioh.0 for ; Thu, 03 Dec 2020 14:14:39 -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=YGJbicdGlx5R58HxNuSypOpg+zzujWdZYBvXORU4Umo=; b=Y0rwTkjwri41iR7mXegPoKtvXGeZhO8Mr//nzvtQY4LKs9jgr/AxyYFcSXZv0jXcOl JhHtFJiwF7bt4WwwGrOx7UzTfd9CFhobh7dh8CJPxKrHM8abKv9Ie1a7YIeLifpvU9nY xU6rz8j/NAixGfd8H0ZJdJQfD8/r+aD1IYh/+60IXI27KMSaCD6Ttembe1+234oe/brj uzgjFFy8gGWGMQagfmu5vYVj063Q8KVZZeF7mCJyN5Cgq2150DlfumuaAL9cgEiCe0Mi hN5MPI0+AyF3rv/l8pyiqOElxX2B8RBK1xILXmlrmlBnqqkE33YJiaw72W8AFPg2ZJLB ZY6A== 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=YGJbicdGlx5R58HxNuSypOpg+zzujWdZYBvXORU4Umo=; b=n613WBIZ+3k/NAguzgyvYcyO3OUtd5XG5Ds9+weANY9MaV9L0a6ayLF1crj3HOQBkL VBpz+W+85wS1KkLf+2VB9ZdsUnvS6H8Hb/BlCfL4XuCEFFjsxigwGZJgK2Lw1kQIjJl4 FaxDXCMqDGkNy4waSE0ZHt2VWTc+mBIHHfKtWIyci6SB5j9gXEDSab5DVHzMz8boNnfQ QWymRsWHqcNy1JVXqlvyvNIfCvg7/6C/3rsV93Nf7XsLo0kA6ruBO2bt9KGaUTjXoFjJ pfAb5x/OE+ryMlEGmSrrEP9uCXdKxWUoGByyHY9L8ta5XJxA4LvZr6kIu1uriNU40t2Z JGVA== X-Gm-Message-State: AOAM530wtsyVrzaTUgJ6fPajgQW+S0i+ssXTZGVoc1++DmmC/MAOcoV4 9pE19+2g+bjVNhV1axk2mPJW0cbz8N6N6w== X-Google-Smtp-Source: ABdhPJwtuMMnu6GQDZD7OP3pKi2uBRv5NF1Nsj1Z/P20MXaUOS46R9F5LGdEJVOKCqBwo29RiGL7KQ== X-Received: by 2002:a02:caac:: with SMTP id e12mr1608759jap.45.1607033678256; Thu, 03 Dec 2020 14:14:38 -0800 (PST) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. [209.85.166.50]) by smtp.gmail.com with ESMTPSA id e1sm288926iod.17.2020.12.03.14.14.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 14:14:37 -0800 (PST) Received: by mail-io1-f50.google.com with SMTP id z136so3760145iof.3 for ; Thu, 03 Dec 2020 14:14:37 -0800 (PST) X-Received: by 2002:a05:6602:22c2:: with SMTP id e2mr1826694ioe.156.1607033676888; Thu, 03 Dec 2020 14:14:36 -0800 (PST) MIME-Version: 1.0 References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> <505DC510-2210-4097-AAFC-B321992555DA@mit.edu> In-Reply-To: <505DC510-2210-4097-AAFC-B321992555DA@mit.edu> From: Aaron Parecki Date: Thu, 3 Dec 2020 14:14:26 -0800 X-Gmail-Original-Message-ID: Message-ID: To: GNAP Mailing List Cc: Fabien Imbault , Yaron Sheffer , Justin Richer Content-Type: multipart/alternative; boundary="00000000000073ff8e05b596af14" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 03 Dec 2020 22:14:43 -0000 --00000000000073ff8e05b596af14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for all the discussion around this so far. On our editors call yesterday we talked about the "Postponed" label and have a new solution that hopefully addresses the feedback from this discussion. The high-level goal with the "Postponed" label was to be able to triage issues quickly while also making it clear that closing an issue doesn't mean we are rejecting the topic of the issue. The "Postponed" label clearly didn't communicate that intent. We will delete the label and instead replace our use of it with both: * Leaving an issue open and adding it to a milestone for the next upcoming IETF meeting * Closing an issue and adding the "Needs Text" label Adding an issue to the milestone of the next meeting will give us a timeline for making sure we come back to that issue, avoiding leaving a lot of hanging issues open with no clear path to move forward. Closing an issue with the "Needs Text" label indicates that there is nothing concrete to do with the issue at the moment, but if someone would like to propose specific text, the issue can be re-opened and discussed further. Justin and Fabien, feel free to chime in to clarify if needed! - Aaron On Mon, Nov 30, 2020 at 9:29 AM Justin Richer wrote: > With the editor hat on: > > A new spec like this is exciting work, and it=E2=80=99s inevitably going = to bring > in lots of ideas of what it could do and what it could incorporate. These > ideas are extremely valuable as they are what push new work into the real= ms > of innovation and possibility and out of the status quo from which it > sprang. But there=E2=80=99s a downside to this stream of ideas: most of t= hem aren=E2=80=99t > solid enough to incorporate in any way. They=E2=80=99re just loose ideas = that maybe > we want to consider, but they don=E2=80=99t have anything we can turn to = and say > =E2=80=9Cwe should build that=E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t b= uild that=E2=80=9D since there isn=E2=80=99t any > =E2=80=9Cthat=E2=80=9D to build. > > The editors have found that many of the issues currently filed seem to fi= t > into this category. There might be an interesting idea in there, but > without something specific to tie the idea to, we don=E2=80=99t have a lo= t to work > with as editors, and there are a lot of other items that the group needs = to > decide and fix first. It=E2=80=99s an issue of triage. > > The goal of the =E2=80=9CPostponed=E2=80=9D tag, as I understand how we= =E2=80=99re using it, is to > tag issues that might need some future discussion, but we aren=E2=80=99t = there yet. > Something tagged as =E2=80=9CPostponed=E2=80=9D but left open long term w= as meant to flag > it as an important detail we should get back to, when we can. Something > tagged =E2=80=9CPostponed=E2=80=9D and closed was meant to flag it as som= ething we might > want to revisit, but only when we=E2=80=99ve got something concrete to wo= rk > against. It=E2=80=99s not meant to say that the group has decided not to = do it, > it=E2=80=99s meant as a way to acknowledge the input and potentially tie = back to it > in the future, even if the issue got closed. > > It seems like the terminology of =E2=80=9CPostponed=E2=80=9D didn=E2=80= =99t quite capture that > intent, and honestly it might not be the best tool for us to use here. I > think we we can work with the idea of IETF meeting-based milestones, as h= as > been suggested by several people. The important outcome is that we don=E2= =80=99t > create a process that=E2=80=99s susceptible to getting buried in =E2=80= =9Cwouldn=E2=80=99t it be > nice if=E2=80=A6=E2=80=9D sentiments to the detriment of forward progress= on a functioning > protocol. Right now, we=E2=80=99ve got a lot of items that amount to poss= ible > future branches, and while we shouldn=E2=80=99t simple forget them, we sh= ouldn=E2=80=99t be > focusing energy on them until someone is able to take the effort to explo= re > that branch. At such a time, we can open a new issue and PR=E2=80=99s for= that, and > link back to these historical artifacts for background and context. By > tying such issues to an IETF meeting milestone, we can put some boundarie= s > on items to keep them from languishing. When the milestone comes up, we c= an > evaluate if there=E2=80=99s something to look at yet or not. > > =E2=80=94 Justin > > On Nov 27, 2020, at 4:03 AM, Fabien Imbault > wrote: > > Hi there, > > One of the potential problems we'd like to avoid is to have an ever > growing list of open issues that we never close. > > The idea of having milestones (e.g. IETF110) might be a complementary way > of managing priorities. > > Editors will revert back to the list after the US vacation days. > > Cheers, > Fabien > > On Thu, Nov 26, 2020 at 1:26 AM Tom Jones > wrote: > >> i agree - drop postponed - if you can't say till when, then close. Issue= s >> can always be added by anyone at anytime. >> Peace ..tom >> >> >> On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer >> wrote: >> >>> Commenting on the proposed process (chair hat off): >>> >>> >>> >>> I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once s= omething is >>> closed, we should be reasonably confident that it is resolved for good. >>> People rarely search through closed issues. >>> >>> >>> >>> Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. = Instead, I >>> suggest to mark such issues with future milestones, e.g. =E2=80=9CIETF1= 10=E2=80=9D, meaning >>> that at this time we will review the issue. Otherwise, the =E2=80=9Cpos= tponed=E2=80=9D >>> issues will probably suffer the destiny of all =E2=80=9Clow priority=E2= =80=9D issues =E2=80=93 they >>> will be ignored for months and eventually closed en masse. See [1] for >>> GitHub milestones. >>> >>> >>> >>> Otherwise I am fine with the rest of the process. >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> [1] >>> https://docs.github.com/en/free-pro-team@latest/github/managing-your-wo= rk-on-github/about-milestones >>> >>> >>> >>> >>> >>> *From: *TXAuth on behalf of Aaron Parecki < >>> aaron@parecki.com> >>> *Date: *Wednesday, November 25, 2020 at 18:37 >>> *To: *GNAP Mailing List >>> *Subject: *[GNAP] GNAP Editors' Use of GitHub Issues >>> >>> >>> >>> The editors met yesterday to discuss the issues that were pulled out of >>> the previous draft text and document a process for how to resolve these= and >>> future issues. We would like to explain how we plan on using labels on >>> GitHub issues to keep track of discussions and keep things moving. >>> >>> When there are substantive issues or pull requests, the editors will >>> avoid merging or closing those outright, and instead mark them as >>> "pending", so that these can be brought to the attention of the larger >>> group. If no additional discussion happens on these, the merge or close >>> action will be taken in 7 days. Note for this first round we are settin= g >>> the deadline for the issues below as Dec 11th due to the US holiday and= the >>> fact that this is the first time using this process. >>> >>> "Pending Merge" >>> When specific text is proposed in a PR (by anyone, not limited to the >>> editors), and the editors believe this text reflects the consensus of t= he >>> working group, this marks that the PR will be merged in 7 days unless t= here >>> is a clear alternative proposal accepted by the working group. >>> >>> "Pending Close" >>> When the editors believe an issue no longer needs discussion, we'll mar= k >>> it "Pending Close". The issue will be closed in 7 days unless someone >>> brings new information to the discussion. This tag is not applied to is= sues >>> that will be closed by a specific pull request. >>> >>> There are two additional labels we will use to flag issues to the group= . >>> >>> "Needs Text" >>> The editors suggest this issue needs additional text in the spec to >>> clarify why this section is needed and under what circumstances. Withou= t a >>> concrete proposal of text to be included in the spec, this section will= be >>> removed in a future update. >>> >>> "Postponed" >>> This issue can be reconsidered in the future with a more concrete >>> discussion but is not targeted for immediate concrete changes to the sp= ec >>> text. When used on its own, this label does not indicate that an issue = is >>> targeted to be closed. An issue may also be marked "Pending Close", and >>> this is used so that we can distinguish closed issues between discussio= ns >>> that have concluded or things that we may want to revisit in the future= . >>> Remember that closed issues are not deleted and their contents are stil= l >>> findable and readable, and that new issues can reference closed issues. >>> >>> With these labels in mind, here are the list of issues and their >>> statuses we were able to discuss on our last editor's call. The action = on >>> these pending issues will be taken on Dec 11th to give the group enough >>> time to review this list. For this first round, many of the issues are >>> marked "Pending Close" as we're looking for low hanging fruit to prune = the >>> list of issues down. In the future, you can expect to see more "Pending >>> Merge" issues as we're bringing proposed text to review by the WG. >>> >>> Postponed: >>> >>> * Generic claim extension mechanism >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 >>> >>> Pending Merge: >>> >>> * Make access token mandatory for continuation API calls >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >>> >>> Postponed and Pending Close: >>> >>> * Fetchable Keys >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 >>> * Including OpenID Connect Claims >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 >>> * Application communication with back-end >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 >>> * Additional post-interaction protocols >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 >>> >>> Pending Close: >>> >>> * HTTP PUT vs POST for rotating access tokens >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 >>> * Use of hash with unique callback URL >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 >>> * Interaction considerations >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 >>> * Expanding dynamic reference handles >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 >>> * Post interaction callback nonce >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 >>> * Unique callback URIs >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 >>> * Instance identifier >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 >>> * Requesting resources by reference >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 >>> * Mapping resource references >>> ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 >>> >>> --- >>> >>> Aaron Parecki >>> >>> https://aaronparecki.com >>> >>> >>> >>> -- TXAuth mailing list TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --00000000000073ff8e05b596af14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for all the discussion around this so far. On our e= ditors call yesterday we talked about the "Postponed" label and h= ave a new solution that hopefully addresses the feedback from this discussi= on.

The high-level goal with the "Postponed" l= abel was to be able to triage issues quickly while also making it clear tha= t closing an issue doesn't mean we are rejecting the topic of the issue= . The "Postponed" label clearly didn't communicate that inten= t. We will delete the label and instead replace our use of it with both:

* Leaving an issue open and adding it to a milestone= for the next upcoming IETF meeting
* Closing an issue and adding= the "Needs Text" label

Adding an issue = to the milestone of the next meeting will give us a timeline for making sur= e we come back to that issue, avoiding leaving a lot of hanging issues open= with no clear path to move forward. Closing an issue with the "Needs = Text" label indicates that there is nothing concrete to do with the is= sue at the moment, but if someone would like to propose specific text, the = issue can be re-opened and discussed further.=C2=A0

Justin=C2=A0and Fabien, feel free to chime in to clarify if needed!
=

- Aaron


On Mon, Nov 30, 2020 at 9:2= 9 AM Justin Richer <jricher@mit.edu> wrote:
With the editor hat on:

A new spec like this is exciting work, and it=E2=80=99s inevitably = going to bring in lots of ideas of what it could do and what it could incor= porate. These ideas are extremely valuable as they are what push new work i= nto the realms of innovation and possibility and out of the status quo from= which it sprang. But there=E2=80=99s a downside to this stream of ideas: m= ost of them aren=E2=80=99t solid enough to incorporate in any way. They=E2= =80=99re just loose ideas that maybe we want to consider, but they don=E2= =80=99t have anything we can turn to and say =E2=80=9Cwe should build that= =E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t build that=E2=80=9D since there = isn=E2=80=99t any =E2=80=9Cthat=E2=80=9D to build.=C2=A0

The editors have found that many of the issues currently filed seem = to fit into this category. There might be an interesting idea in there, but= without something specific to tie the idea to, we don=E2=80=99t have a lot= to work with as editors, and there are a lot of other items that the group= needs to decide and fix first. It=E2=80=99s an issue of triage.
=
The goal of the =E2=80=9CPostponed=E2=80=9D tag, as I unders= tand how we=E2=80=99re using it, is to tag issues that might need some futu= re discussion, but we aren=E2=80=99t there yet. Something tagged as =E2=80= =9CPostponed=E2=80=9D but left open long term was meant to flag it as an im= portant detail we should get back to, when we can. Something tagged =E2=80= =9CPostponed=E2=80=9D and closed was meant to flag it as something we might= want to revisit, but only when we=E2=80=99ve got something concrete to wor= k against. It=E2=80=99s not meant to say that the group has decided not to = do it, it=E2=80=99s meant as a way to acknowledge the input and potentially= tie back to it in the future, even if the issue got closed.

=
It seems like the terminology of =E2=80=9CPostponed=E2=80=9D did= n=E2=80=99t quite capture that intent, and honestly it might not be the bes= t tool for us to use here. I think we we can work with the idea of IETF mee= ting-based milestones, as has been suggested by several people. The importa= nt outcome is that we don=E2=80=99t create a process that=E2=80=99s suscept= ible to getting buried in =E2=80=9Cwouldn=E2=80=99t it be nice if=E2=80=A6= =E2=80=9D sentiments to the detriment of forward progress on a functioning = protocol. Right now, we=E2=80=99ve got a lot of items that amount to possib= le future branches, and while we shouldn=E2=80=99t simple forget them, we s= houldn=E2=80=99t be focusing energy on them until someone is able to take t= he effort to explore that branch. At such a time, we can open a new issue a= nd PR=E2=80=99s for that, and link back to these historical artifacts for b= ackground and context. By tying such issues to an IETF meeting milestone, w= e can put some boundaries on items to keep them from languishing. When the = milestone comes up, we can evaluate if there=E2=80=99s something to look at= yet or not.

=C2=A0=E2=80=94 Justin

=

Hi there,=C2= =A0

One of the potential problems we'd like to avoid= is to have an ever growing list of open issues that we never close.=C2=A0<= /div>

The idea of having milestones (e.g. IETF110) might= be a complementary way of managing priorities.

Ed= itors=C2=A0will revert back to the list after the US vacation days.

Cheers,
Fabien

On Thu, Nov 26, 2020 at 1:2= 6 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
i agree - drop pos= tponed=C2=A0- if you can't say till when, then close. Issues can always= be added by anyone at anytime.
Peace ..tom


On Wed, Nov 25, 20= 20 at 10:27 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Commenting on the proposed process (chair hat off):

=C2=A0

= I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once somet= hing is closed, we should be reasonably confident that it is resolved for g= ood. People rarely search through closed issues.

=C2=A0

Moreover, IMO= the label =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, I sugges= t to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80= =9D, meaning that at this time we will review the issue. Otherwise, the =E2= =80=9Cpostponed=E2=80=9D issues will probably suffer the destiny of all =E2= =80=9Clow priority=E2=80=9D issues =E2=80=93 they will be ignored for month= s and eventually closed en masse. See [1] for GitHub milestones.<= /u>

=C2=A0

Otherwise I am fine with the rest of the process.

=C2=A0

Thanks,<= /u>

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

=C2=A0

[1= ] https://docs.gith= ub.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-mi= lestones

=C2=A0

=C2=A0

From: TXAuth <txauth-bounces@ietf.o= rg> on behalf of Aaron Parecki <aaron@parecki.com>
Date: Wednesday, = November 25, 2020 at 18:37
To: GNAP Mailing List <txauth@ietf.org>
Subj= ect: [GNAP] GNAP Editors' Use of GitHub Issues=

=C2=A0

The editors met yesterday= to discuss the issues that were pulled out of the previous draft text and = document a process for how to resolve these and future issues. We would lik= e to explain how we plan on using labels on GitHub issues to keep track of = discussions and keep things moving.

When there are substantive issue= s or pull requests, the editors will avoid merging or closing those outrigh= t, and instead mark them as "pending", so that these can be broug= ht to the attention of the larger group. If no additional discussion happen= s on these, the merge or close action will be taken in 7 days. Note for thi= s first round we are setting the deadline for the issues below as Dec 11th = due to the US holiday and the fact that this is the first time using this p= rocess.

"Pending Merge"
When specific text is proposed = in a PR (by anyone, not limited to the editors), and the editors believe th= is text reflects the consensus of the working group, this marks that the PR= will be merged in 7 days unless there is a clear alternative proposal acce= pted by the working group.

"Pending Close"
When the edi= tors believe an issue no longer needs discussion, we'll mark it "P= ending Close". The issue will be closed in 7 days unless someone bring= s new information to the discussion. This tag is not applied to issues that= will be closed by a specific pull request.

There are two additional= labels we will use to flag issues to the group.

"Needs Text&qu= ot;
The editors suggest this issue needs additional text in the spec to = clarify why this section is needed and under what circumstances. Without a = concrete proposal of text to be included in the spec, this section will be = removed in a future update.

"Postponed"
This issue can = be reconsidered in the future with a more concrete discussion but is not ta= rgeted for immediate concrete changes to the spec text. When used on its ow= n, this label does not indicate that an issue is targeted to be closed. An = issue may also be marked "Pending Close", and this is used so tha= t we can distinguish closed issues between discussions that have concluded = or things that we may want to revisit in the future. Remember that closed i= ssues are not deleted and their contents are still findable and readable, a= nd that new issues can reference closed issues.

With these labels in= mind, here are the list of issues and their statuses we were able to discu= ss on our last editor's call. The action on these pending issues will b= e taken on Dec 11th to give the group enough time to review this list. For = this first round, many of the issues are marked "Pending Close" a= s we're looking for low hanging fruit to prune the list of issues down.= In the future, you can expect to see more "Pending Merge" issues= as we're bringing proposed text to review by the WG.

Postponed:=

* Generic claim extension mechanism
** https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/131

Pending Me= rge:

* Make access token mandatory for continuation API calls
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129<= /a>

Postponed and Pending Close:

* Fetchable Keys
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Including OpenID Connect Claims
** https://github= .com/ietf-wg-gnap/gnap-core-protocol/issues/64
* Application communi= cation with back-end
** https://github.com/ietf-wg-gnap/= gnap-core-protocol/issues/82
* Additional post-interaction protocols=
** https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/83

Pending Close:
=C2=A0 =C2=A0
* HTTP PUT vs POST = for rotating access tokens
** https://github.com/ietf-w= g-gnap/gnap-core-protocol/issues/100
* Use of hash with unique callb= ack URL
** https://github.com/ietf-wg-gnap/gnap-core-pro= tocol/issues/84
* Interaction considerations
** h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81
* Expand= ing dynamic reference handles
** https://github.com/ietf= -wg-gnap/gnap-core-protocol/issues/76
* Post interaction callback no= nce
** https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/73
* Unique callback URIs
** https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/55
* Instance identi= fier
** https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/issues/46
* Requesting resources by reference
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
* Ma= pping resource references
** https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/35

=

---

Aa= ron Parecki

=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
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--00000000000073ff8e05b596af14-- From nobody Fri Dec 4 07:56:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15823A0DAC for ; Fri, 4 Dec 2020 07:56:46 -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 mQg2wUs06wQF for ; Fri, 4 Dec 2020 07:56:45 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 4F75F3A0DB4 for ; Fri, 4 Dec 2020 07:56:39 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id 81so6189119ioc.13 for ; Fri, 04 Dec 2020 07:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=pSznNX/WFLRz8lJQktqdCeB+aUQk+2vE9JHCLWX3Le4=; b=ZoXiKc6xywE7bWzx1l0b1Wk8XsDrVnPX0wwi3zhRpfhucgliEGEM8/9Ds/hrFkt4m8 4PbuynAWxbSLQZWqVsBTv6+oMki94KztZACB8Riizk+1K7UxwgDtHeRGZSqIWKWGwDHD P5Fmm19xsJXoQ257kfo/q/OPTiQz4zQsG/HGKLMC6dMSPV+/MssI8ef61k0OcijpDrSa /MFTaXNibKoecpYrbMklXkTbeVSbZpwT4P4eHILAo4rIMOTFBH3mJnE7O6mIs9KvAFoW LUiFdC/7tRjxD4+vhgnfF/kaD2ZgJcYS9uAK6K9mllqCfaLwkA/+Cqj6mruHfjHbmDmP gGZQ== 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=pSznNX/WFLRz8lJQktqdCeB+aUQk+2vE9JHCLWX3Le4=; b=CUlkV0u/YQHBcUcvetBJcYHikl+aaqPgyxp9kmeHhy/3kgNO0X7hWZNxMXgT4aL/eI c7VGweIOdwZMQT1TxbX/tTBXamngDBOJrSM5Ud8VLScaeekuEPs5J8ALiDV2dcKWV9RV DPPRv+r69mlMYBr+yLjmkmuwTzptzx70YdMvvHymSTIhMP+UzJ6EYWmT8huKS4IYcs+J Q4nYsu6KYfVGNU16WgXFoEaBviKKut76coBq9e6F3PqPOdWNb9MQMrAsrNnvyPvXHQL3 QzbgwoG4YGrXViW1n0LNgBCUAzZrDQWbfxoKh5fGQWny3yObd8Cvd7qdRR+Y28M9PHIB ivbg== X-Gm-Message-State: AOAM530FYGijScDIWqqG6RLQV9FgQ8pnIcDsY/Xj2o6bRAyTZWLQehOz XyV6a7Qgje3H0dZlXZY1ZU4Ry0/Vyo2Ccg== X-Google-Smtp-Source: ABdhPJyZgwyVqR+aUXkBQRFUGMzlBllFpusO++rmaN2nazHJeY1c1ih8bWDN9ddviLySEGo7vIeVdQ== X-Received: by 2002:a02:23ce:: with SMTP id u197mr7220675jau.113.1607097397832; Fri, 04 Dec 2020 07:56:37 -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 w3sm1705495iol.9.2020.12.04.07.56.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 07:56:37 -0800 (PST) Received: by mail-io1-f49.google.com with SMTP id q137so6213861iod.9 for ; Fri, 04 Dec 2020 07:56:36 -0800 (PST) X-Received: by 2002:a02:aa83:: with SMTP id u3mr7369359jai.38.1607097396635; Fri, 04 Dec 2020 07:56:36 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Fri, 4 Dec 2020 07:56:25 -0800 X-Gmail-Original-Message-ID: Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000722ed805b5a58521" Archived-At: Subject: [GNAP] still getting used to this new GitHub workflow 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, 04 Dec 2020 15:56:47 -0000 --000000000000722ed805b5a58521 Content-Type: text/plain; charset="UTF-8" Just wanted to shoot a quick email to the list to apologize for a little mistake this morning before I had my coffee. I was processing my emails and saw Justin had approved a PR I had made yesterday to address two issues, and seeing the bright green "merge" button and a PR approval, clicked "merge" before remembering that our process is to first add the "pending merge" label and wait a week for feedback. We realized what happened pretty quick, and made a call to roll everything back so that the PR can go through the established process. Since this happened pretty quick, we decided to do a force push to remove the merge commit from the "main" branch, and then re-create the PR. If you happened to pull the GitHub "main" branch between 15:15-15:30 UTC you will have pulled the merge commit that we overwrote with a force push. You'll want to roll back to the latest commit prior to that, 9931fdfd245be58f27d91c36fa8567667a27cbb4. My apologies, and we'll try to make sure this doesn't happen again! If it does, we might add some tooling using GitHub actions to prevent accidental merges in the future. --- Aaron Parecki https://aaronparecki.com --000000000000722ed805b5a58521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just wanted to shoot a quick email to the list to apo= logize for a little mistake this morning before I had my coffee.=C2=A0

I was processing my emails and saw Justin had approved= a PR I had made yesterday to address two issues, and seeing the bright gre= en "merge" button and a PR approval, clicked "merge" be= fore remembering that our process is to first add the "pending merge&q= uot; label and wait a week for feedback.=C2=A0

We = realized what happened pretty quick, and made a call to roll everything bac= k so that the PR can go through the established process. Since this happene= d pretty=C2=A0quick, we decided to do a force push to remove the merge comm= it from the "main" branch, and then re-create the PR.
<= br>
If you happened to pull the GitHub "main" branch be= tween 15:15-15:30 UTC you will have pulled the merge commit that we overwro= te with a force push. You'll want to roll back to the latest commit pri= or=C2=A0to that,=C2=A09931fdfd245be58f27d91c36fa8567667a27cbb4.
<= br>
My apologies, and we'll try to make sure this doesn't= happen again! If it does, we might add some tooling using GitHub actions t= o prevent accidental merges in the future.

<= div dir=3D"ltr">
---
Aaron Parecki

--000000000000722ed805b5a58521-- From nobody Sat Dec 5 23:41:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2D93A0E6B for ; Sat, 5 Dec 2020 23:40:57 -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_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=T0V6LJ+2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c3oYicbl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKR2_2HLmtzD for ; Sat, 5 Dec 2020 23:40:55 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D891C3A0E7B for ; Sat, 5 Dec 2020 23:40:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6E4F25C0135 for ; Sun, 6 Dec 2020 02:35:13 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 06 Dec 2020 02:35:13 -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=bVtAQ/7sjlCnZmQpPSsOkeWMP4tUMWu7odYn1C1ifiU=; b=T0V6LJ+2 41caj2/u5uyVZP7InAe4kbejIQkMkXaK12KeJyKtLAEB2/tTKdCcoEpvyiCcEreb Hm3/UtDtsq9+8IRdCxWht1lgs8iGEinhzv8vxwWXWFpnhKP20j89Qqopof4fAjvT VzrXfOCEje8+pljXY45rU1FyqRFRnf9B/pKK00480PRRb82PaxvTsgSMkm+VJtmK nQ8BZ4CBrjrsM1iobP7RFx33ilABcSRN4F4oCW7/89PR/LPLPrBeEwHApG/imAEW ZL8nZ4Ohe6/r32sW+ZWcAqyw3MYLn2nIW+/gVwBcqTRwk2G0F7VqLEVwuRgzffRf FiaP64hb+L6D5Q== 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=bVtAQ/7sjlCnZmQpPSsOkeWMP4tUM Wu7odYn1C1ifiU=; b=c3oYicblKdxLKr7BCAQRdyHihFgg3VC+Q0Wc404n1gGEM uzxXyZlWzANHBGPo9IxyuTaVruJ7X7GrSn19u/oyUzZOJ0zUVxZHGxpPsi84aZIv /QIdfIjU1wZ839gNGMZdAri6CSLLmNvbHudjAcp8woczYHEcLiXX/ARzMgxkqrbY jATDXk3DJNKtVaPCcN0/qIQYQ2pa3YpQo0mFHNDto7IovXAY+p6vlieUo9yLidac 31XSk4CSnURhPkPMn16//u4VzH6sNu5wLmVRm2P9KZE2ADe/7B91jmDGshv4m4qE ICHdBKW7NRTVpnTtLd9cVCN6SY/9p36dDegW6pWrQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejuddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvfedtrd dukeenucevlhhushhtvghrufhiiigvpeehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60-565.internal.cloudapp.net (unknown [40.65.230.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 419B324005D for ; Sun, 6 Dec 2020 02:35:13 -0500 (EST) Content-Type: multipart/alternative; boundary="===============1268508723806252947==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201206073513.419B324005D@mailuser.nyi.internal> Date: Sun, 6 Dec 2020 02:35: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, 06 Dec 2020 07:40:57 -0000 --===============1268508723806252947== 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 (+4/-1/=F0=9F=92=AC33) 4 issues created: - Request element "capabilities" collides with adjacent industry terminol= ogy (by tplooker) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/137=20 - security assessment of the protocol (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/135=20 - Guidance for Extensions (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/134=20 - Privacy considerations (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133=20 23 issues received 33 new comments: - #111 Key redundancy in DPoP method (2 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/111 [Pending = Close]=20 - #110 Validation of MTLS signature method (1 by TomCJones) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/110=20 - #108 Fragility of JOSE-based signature methods (2 by TomCJones, fimbaul= t) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/108=20 - #107 Detached-JWS header (3 by TomCJones, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/107=20 - #106 JWS Headers for JOSE-based signature methods (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/106=20 - #100 HTTP PUT vs POST for rotating access tokens (1 by TomCJones) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 [Pending = Close]=20 - #99 Updating and reading access tokens (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/99=20 - #85 Key rotation within continuation (2 by TomCJones, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/85=20 - #84 Use of hash with unique callback URL (2 by dickhardt) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 [Pending C= lose]=20 - #80 Response Extensions (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/80=20 - #74 Privacy considerations of returned user information (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/74=20 - #68 Syntax for single and multiple access tokens (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/68=20 - #66 Continuation access token use outside of continuation requests (4 b= y fimbault, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66=20 - #65 Guidance for Grant Request Extensions (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/65=20 - #63 Splitting the "claims" request (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/63=20 - #61 Provide guidance for defining new interactions (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/61=20 - #55 Unique callback URIs (1 by dickhardt) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 [Pending C= lose]=20 - #52 Create more examples of interaction modes (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/52=20 - #40 Access token request format (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/40=20 - #34 Alignment with RAR (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/34 [Pending C= lose]=20 - #33 Non-role protocol elements (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/33 [Pending C= lose]=20 - #30 Structure of the spec (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/30 [Pending C= lose]=20 - #9 Clarify User-Code Interaction (2 by TomCJones, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/9=20 1 issues closed: - Including OpenID Connect claims https://github.com/ietf-wg-gnap/gnap-co= re-protocol/issues/64 [Needs Text] [Pending Close]=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+4/-1/=F0=9F=92=AC38) 4 pull requests submitted: - drop examples of requesting OIDC claims (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/140=20 - drop "Redirect to a Shortened URL" (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/139=20 - drop examples of requesting OIDC claims (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/138=20 - Clarify the nature of access requests, closes #12 (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/136=20 5 pull requests received 38 new comments: - #139 drop "Redirect to a Shortened URL" (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/139=20 - #138 drop examples of requesting OIDC claims (2 by aaronpk, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/138=20 - #136 Clarify the nature of access requests, closes #12 (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/136=20 - #132 Changed "resource client (RC)" to "client instance (CI)" (30 by To= mCJones, aaronpk, dickhardt, fimbault, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132=20 - #129 Make access token mandatory for continuation API calls. (4 by dick= hardt, fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 [Pending Me= rge]=20 1 pull requests merged: - drop examples of requesting OIDC claims https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/138=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============1268508723806252947== 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 December 06, 2020

Events without label "editorial"

Issues

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

4 issues created:

23 issues received 33 new comments:

1 issues closed:

Pull requests

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

4 pull requests submitted:

5 pull requests received 38 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============1268508723806252947==-- From nobody Sun Dec 6 09:17:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CBF3A0418 for ; Sun, 6 Dec 2020 09:17:08 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgxffjquZE6G for ; Sun, 6 Dec 2020 09:17:04 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0A53A044E for ; Sun, 6 Dec 2020 09:17:04 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id e25so11560434wme.0 for ; Sun, 06 Dec 2020 09:17:04 -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=270R+UqkXoKcI5uIlbmrAcY9h1PfKlg0oG1+NIC3mZk=; b=LTOWUdm031K1IHCBfE7f7nqyf1ZVsid64oUVZIi+To8VCxtkGn0yf0HZr3c8nN9PCA jdHbZSdiZoWBEUZIKO8mCq0p5zt7E3FHi1UimlVRKcRp+Z3JnLD2MLEWItBGlHc4o588 e0n2H/Yueyqwr5/ljEtRAzDmYm7AplGaxiDi8nkRTzSSEwbyTQ+5Fu1MEkBuDCrlqcXL +eQ1M2Bcs1Zh8MNrJgOGeolifVCG1Qd6K3DJb5ZKmLZdghUJIJBD1EBcsM2umQvdfbDe F1wEADkOIohRuxC2r2mwECoAGYB9sUSIKuFA6KuBzEHII96PUZE10mhArey4EuoHqiXX Attg== 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=270R+UqkXoKcI5uIlbmrAcY9h1PfKlg0oG1+NIC3mZk=; b=l7u95JH0bi0AvRbYT92nvuOkBVNd0yO6isLqjBji55JiixoAlLoK1G1bWrt8211Qnv xULm3FJwEM/YGV7bOZPJqUz9PZDVk6a3mHHaeMnuBN+T6ZTh0/B1YEQDtbA3WgmF4PXw KWQwWYoivTPtl9mVhMroRGOTnP2VHsHTrM2FxvRRbG5bFFNCrBFv7UiA+rQKLAg3eovD FlIjOY/EyI4a/zidECAvSZdQ0OTNylZ2iHe9oLKnt753PMIFZt1vGshAiBN4Y3psWvlR BKFHToYYBHnJknX6apFLDzwIygQ5qHkp6C7kT0UFffSacdzgS0SZ4sWF57lL+Swa0rWP PxuA== X-Gm-Message-State: AOAM531sHsL01w1TMAC6lA3RUU8cVG/KYVzyrPBC6jh4kWZmiZYCDdhu z01gf3//zRlv6hONSCpdfLA= X-Google-Smtp-Source: ABdhPJySx7ZbRjGH/R4iUwiFI0OIhimcAgov0lUYTYbvQzNm/CzkYVLJXnAJ4ph3x8LaQuA8XvYdBQ== X-Received: by 2002:a1c:730c:: with SMTP id d12mr14431559wmb.3.1607275022338; Sun, 06 Dec 2020 09:17:02 -0800 (PST) Received: from [192.168.68.107] (bzq-79-178-108-177.red.bezeqint.net. [79.178.108.177]) by smtp.gmail.com with ESMTPSA id x66sm10945466wmg.26.2020.12.06.09.17.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Dec 2020 09:17:01 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Sun, 06 Dec 2020 19:16:59 +0200 From: Yaron Sheffer To: Aaron Parecki , GNAP Mailing List CC: Fabien Imbault , Justin Richer Message-ID: <45958447-4336-4CB3-BB4C-36E948474390@gmail.com> Thread-Topic: [GNAP] GNAP Editors' Use of GitHub Issues References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> <505DC510-2210-4097-AAFC-B321992555DA@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3690127020_868984653" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 06 Dec 2020 17:17:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3690127020_868984653 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Regarding issues being closed with =E2=80=9Cneeds text=E2=80=9D, I don=E2=80=99t think people= are going to scour the closed issues looking for interesting stuff =F0=9F=98=8A. As= I said in the past, nobody cares for closed issues. =20 Instead, I suggest to take these issues to the list and ask people to provi= de text. If nobody does, say within a week, close the issue. =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: Friday, December 4, 2020 at 00:14 To: GNAP Mailing List Cc: Fabien Imbault , Yaron Sheffer , Justin Richer Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues =20 Thanks for all the discussion around this so far. On our editors call yeste= rday we talked about the "Postponed" label and have a new solution that hope= fully addresses the feedback from this discussion. =20 The high-level goal with the "Postponed" label was to be able to triage iss= ues quickly while also making it clear that closing an issue doesn't mean we= are rejecting the topic of the issue. The "Postponed" label clearly didn't = communicate that intent. We will delete the label and instead replace our us= e of it with both: =20 * Leaving an issue open and adding it to a milestone for the next upcoming = IETF meeting * Closing an issue and adding the "Needs Text" label =20 Adding an issue to the milestone of the next meeting will give us a timelin= e for making sure we come back to that issue, avoiding leaving a lot of hang= ing issues open with no clear path to move forward. Closing an issue with th= e "Needs Text" label indicates that there is nothing concrete to do with the= issue at the moment, but if someone would like to propose specific text, th= e issue can be re-opened and discussed further.=20 =20 Justin and Fabien, feel free to chime in to clarify if needed! =20 - Aaron =20 =20 On Mon, Nov 30, 2020 at 9:29 AM Justin Richer wrote: With the editor hat on: =20 A new spec like this is exciting work, and it=E2=80=99s inevitably going to bring= in lots of ideas of what it could do and what it could incorporate. These i= deas are extremely valuable as they are what push new work into the realms o= f innovation and possibility and out of the status quo from which it sprang.= But there=E2=80=99s a downside to this stream of ideas: most of them aren=E2=80=99t sol= id enough to incorporate in any way. They=E2=80=99re just loose ideas that maybe w= e want to consider, but they don=E2=80=99t have anything we can turn to and say =E2=80= =9Cwe should build that=E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t build that=E2=80=9D since there isn=E2= =80=99t any =E2=80=9Cthat=E2=80=9D to build.=20 =20 The editors have found that many of the issues currently filed seem to fit = into this category. There might be an interesting idea in there, but without= something specific to tie the idea to, we don=E2=80=99t have a lot to work with a= s editors, and there are a lot of other items that the group needs to decide= and fix first. It=E2=80=99s an issue of triage. =20 The goal of the =E2=80=9CPostponed=E2=80=9D tag, as I understand how we=E2=80=99re using it, = is to tag issues that might need some future discussion, but we aren=E2=80=99t the= re yet. Something tagged as =E2=80=9CPostponed=E2=80=9D but left open long term was mean= t to flag it as an important detail we should get back to, when we can. Some= thing tagged =E2=80=9CPostponed=E2=80=9D and closed was meant to flag it as something we= might want to revisit, but only when we=E2=80=99ve got something concrete to work= against. It=E2=80=99s not meant to say that the group has decided not to do it, i= t=E2=80=99s meant as a way to acknowledge the input and potentially tie back to it= in the future, even if the issue got closed. =20 It seems like the terminology of =E2=80=9CPostponed=E2=80=9D didn=E2=80=99t quite capture tha= t intent, and honestly it might not be the best tool for us to use here. I t= hink we we can work with the idea of IETF meeting-based milestones, as has b= een suggested by several people. The important outcome is that we don=E2=80=99t cr= eate a process that=E2=80=99s susceptible to getting buried in =E2=80=9Cwouldn=E2=80=99t it be= nice if=E2=80=A6=E2=80=9D sentiments to the detriment of forward progress on a function= ing protocol. Right now, we=E2=80=99ve got a lot of items that amount to possible = future branches, and while we shouldn=E2=80=99t simple forget them, we shouldn=E2=80=99t= be focusing energy on them until someone is able to take the effort to expl= ore that branch. At such a time, we can open a new issue and PR=E2=80=99s for that= , and link back to these historical artifacts for background and context. By= tying such issues to an IETF meeting milestone, we can put some boundaries = on items to keep them from languishing. When the milestone comes up, we can = evaluate if there=E2=80=99s something to look at yet or not. =20 =E2=80=94 Justin On Nov 27, 2020, at 4:03 AM, Fabien Imbault wrot= e: =20 Hi there,=20 =20 One of the potential problems we'd like to avoid is to have an ever growing= list of open issues that we never close.=20 =20 The idea of having milestones (e.g. IETF110) might be a complementary way o= f managing priorities. =20 Editors will revert back to the list after the US vacation days. =20 Cheers, Fabien =20 On Thu, Nov 26, 2020 at 1:26 AM Tom Jones wr= ote: i agree - drop postponed - if you can't say till when, then close. Issues c= an always be added by anyone at anytime. Peace ..tom =20 =20 On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer wrot= e: Commenting on the proposed process (chair hat off): =20 I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once something is clos= ed, we should be reasonably confident that it is resolved for good. People r= arely search through closed issues. =20 Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, I sugge= st to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80=9D, meaning t= hat at this time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2=80=9D is= sues will probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 t= hey will be ignored for months and eventually closed en masse. See [1] for G= itHub milestones. =20 Otherwise I am fine with the rest of the process. =20 Thanks, Yaron =20 [1] https://docs.github.com/en/free-pro-team@latest/github/managing-your-wo= rk-on-github/about-milestones =20 =20 From: TXAuth on behalf of Aaron Parecki Date: Wednesday, November 25, 2020 at 18:37 To: GNAP Mailing List Subject: [GNAP] GNAP Editors' Use of GitHub Issues =20 The editors met yesterday to discuss the issues that were pulled out of the= previous draft text and document a process for how to resolve these and fut= ure issues. We would like to explain how we plan on using labels on GitHub i= ssues to keep track of discussions and keep things moving. When there are substantive issues or pull requests, the editors will avoid = merging or closing those outright, and instead mark them as "pending", so th= at these can be brought to the attention of the larger group. If no addition= al discussion happens on these, the merge or close action will be taken in 7= days. Note for this first round we are setting the deadline for the issues = below as Dec 11th due to the US holiday and the fact that this is the first = time using this process. "Pending Merge" When specific text is proposed in a PR (by anyone, not limited to the edito= rs), and the editors believe this text reflects the consensus of the working= group, this marks that the PR will be merged in 7 days unless there is a cl= ear alternative proposal accepted by the working group. "Pending Close" When the editors believe an issue no longer needs discussion, we'll mark it= "Pending Close". The issue will be closed in 7 days unless someone brings n= ew information to the discussion. This tag is not applied to issues that wil= l be closed by a specific pull request. There are two additional labels we will use to flag issues to the group. "Needs Text" The editors suggest this issue needs additional text in the spec to clarify= why this section is needed and under what circumstances. Without a concrete= proposal of text to be included in the spec, this section will be removed i= n a future update. "Postponed" This issue can be reconsidered in the future with a more concrete discussio= n but is not targeted for immediate concrete changes to the spec text. When = used on its own, this label does not indicate that an issue is targeted to b= e closed. An issue may also be marked "Pending Close", and this is used so t= hat we can distinguish closed issues between discussions that have concluded= or things that we may want to revisit in the future. Remember that closed i= ssues are not deleted and their contents are still findable and readable, an= d that new issues can reference closed issues. With these labels in mind, here are the list of issues and their statuses w= e were able to discuss on our last editor's call. The action on these pendin= g issues will be taken on Dec 11th to give the group enough time to review t= his list. For this first round, many of the issues are marked "Pending Close= " as we're looking for low hanging fruit to prune the list of issues down. I= n the future, you can expect to see more "Pending Merge" issues as we're bri= nging proposed text to review by the WG. Postponed: * Generic claim extension mechanism ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 Pending Merge: * Make access token mandatory for continuation API calls ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 Postponed and Pending Close: * Fetchable Keys ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 * Including OpenID Connect Claims ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 * Application communication with back-end ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 * Additional post-interaction protocols ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 Pending Close: =20 * HTTP PUT vs POST for rotating access tokens ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 * Use of hash with unique callback URL ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 * Interaction considerations ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 * Expanding dynamic reference handles ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 * Post interaction callback nonce ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 * Unique callback URIs=20 ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 * Instance identifier ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 * Requesting resources by reference ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 * Mapping resource references ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 --- Aaron Parecki https://aaronparecki.com =20 -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --B_3690127020_868984653 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Regarding issues bein= g closed with =E2=80=9Cneeds text=E2=80=9D, I don=E2=80=99t think people are going to scour th= e closed issues looking for interesting stuff 😊. As I said in the past, nobody cares for cl= osed issues.

 

Instead, I suggest to take these issues to the list and ask people= to provide text. If nobody does, say within a week, close the issue.

 

Thanks,

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

 

<= span style=3D'font-size:12.0pt;color:black'>From: Aaron Parecki <aaron@parecki.com>
Date= : Friday, December 4, 2020 at 00:14
To: GNAP Mailing List <= txauth@ietf.org>
Cc: Fabien Imbault <fabien.imbault@gmail.co= m>, Yaron Sheffer <yaronf.ietf@gmail.com>, Justin Richer <jriche= r@mit.edu>
Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issu= es

 

<= /div>

Thanks for all the discussion around this so fa= r. On our editors call yesterday we talked about the "Postponed" l= abel and have a new solution that hopefully addresses the feedback from this= discussion.

 

The high-level goal with the "Postponed"= label was to be able to triage issues quickly while also making it clear th= at closing an issue doesn't mean we are rejecting the topic of the issue. Th= e "Postponed" label clearly didn't communicate that intent. We wil= l delete the label and instead replace our use of it with both:

 

* Leaving an issue open and adding it to a milestone for the next upc= oming IETF meeting

* Closing an = issue and adding the "Needs Text" label

<= p class=3DMsoNormal> 

Adding = an issue to the milestone of the next meeting will give us a timeline for ma= king sure we come back to that issue, avoiding leaving a lot of hanging issu= es open with no clear path to move forward. Closing an issue with the "= Needs Text" label indicates that there is nothing concrete to do with t= he issue at the moment, but if someone would like to propose specific text, = the issue can be re-opened and discussed further. 

=

 

J= ustin and Fabien, feel free to chime in to clarify if needed!

 

- Aaron

 

 

On Mon, Nov 30, 2020 at 9:29 AM Justin Richer <jricher@mit.edu> wrote:

With the = editor hat on:

 

A new spec like this is exciting work, and it=E2=80=99= s inevitably going to bring in lots of ideas of what it could do and what it= could incorporate. These ideas are extremely valuable as they are what push= new work into the realms of innovation and possibility and out of the statu= s quo from which it sprang. But there=E2=80=99s a downside to this stream of ideas= : most of them aren=E2=80=99t solid enough to incorporate in any way. They=E2=80=99re ju= st loose ideas that maybe we want to consider, but they don=E2=80=99t have anythin= g we can turn to and say =E2=80=9Cwe should build that=E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t bui= ld that=E2=80=9D since there isn=E2=80=99t any =E2=80=9Cthat=E2=80=9D to build. 

=

 

The editors have found that many of the issues currently filed seem to = fit into this category. There might be an interesting idea in there, but wit= hout something specific to tie the idea to, we don=E2=80=99t have a lot to work wi= th as editors, and there are a lot of other items that the group needs to de= cide and fix first. It=E2=80=99s an issue of triage.

 

The goal o= f the =E2=80=9CPostponed=E2=80=9D tag, as I understand how we=E2=80=99re using it, is to tag i= ssues that might need some future discussion, but we aren=E2=80=99t there yet. Som= ething tagged as =E2=80=9CPostponed=E2=80=9D but left open long term was meant to flag i= t as an important detail we should get back to, when we can. Something tagge= d =E2=80=9CPostponed=E2=80=9D and closed was meant to flag it as something we might want= to revisit, but only when we=E2=80=99ve got something concrete to work against. I= t=E2=80=99s not meant to say that the group has decided not to do it, it=E2=80=99s meant= as a way to acknowledge the input and potentially tie back to it in the fut= ure, even if the issue got closed.

 

It seems like the term= inology of =E2=80=9CPostponed=E2=80=9D didn=E2=80=99t quite capture that intent, and honestly = it might not be the best tool for us to use here. I think we we can work wit= h the idea of IETF meeting-based milestones, as has been suggested by severa= l people. The important outcome is that we don=E2=80=99t create a process that=E2=80=99s= susceptible to getting buried in =E2=80=9Cwouldn=E2=80=99t it be nice if=E2=80=A6=E2=80=9D sentimen= ts to the detriment of forward progress on a functioning protocol. Right now= , we=E2=80=99ve got a lot of items that amount to possible future branches, and wh= ile we shouldn=E2=80=99t simple forget them, we shouldn=E2=80=99t be focusing energy on = them until someone is able to take the effort to explore that branch. At suc= h a time, we can open a new issue and PR=E2=80=99s for that, and link back to thes= e historical artifacts for background and context. By tying such issues to a= n IETF meeting milestone, we can put some boundaries on items to keep them f= rom languishing. When the milestone comes up, we can evaluate if there=E2=80=99s s= omething to look at yet or not.

=  

 =E2=80=94 Justin



On Nov 27, 2= 020, at 4:03 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

 

Hi th= ere, 

 

=

One of the potential problems we'd like to avoid is = to have an ever growing list of open issues that we never close. <= /o:p>

 

The idea of having milestones (e.g. IETF110) might be a comple= mentary way of managing priorities.

 

Editors will rev= ert back to the list after the US vacation days.

 

Cheers,<= o:p>

Fabien

 

On Thu= , Nov 26, 2020 at 1:26 AM Tom Jones <thomasclinganjones@gmail.com> wrote:

i agree - drop postponed - if you can't say till when, then = close. Issues can always be added by anyone at anytime.

Peace ..tom

 

 

On Wed, Nov 25, = 2020 at 10:27 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Commenting on the pr= oposed process (chair hat off):

 

I thi= nk =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once something is closed, we= should be reasonably confident that it is resolved for good. People rarely = search through closed issues.

 

Moreove= r, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, I suggest to ma= rk such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80=9D, meaning that at t= his time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2=80=9D issues wil= l probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues =E2=80=93 they will= be ignored for months and eventually closed en masse. See [1] for GitHub mi= lestones.

 

Otherwise I am fine with th= e rest of the process.

 

Thanks,

           =      Yaron

 

[1] https://docs.github.com/en/= free-pro-team@latest/github/managing-your-work-on-github/about-milestones

 

 

From: = TXAuth <txauth-b= ounces@ietf.org> on behalf of Aaron Parecki <aaron@parecki.com>
Date: Wedn= esday, November 25, 2020 at 18:37
To: GNAP Mailing List <txauth@ietf.org>
Sub= ject: [GNAP] GNAP Editors' Use of GitHub Issues

 

The editors met yesterday to discuss t= he issues that were pulled out of the previous draft text and document a pro= cess for how to resolve these and future issues. We would like to explain ho= w we plan on using labels on GitHub issues to keep track of discussions and = keep things moving.

When there are substantive issues or pull request= s, the editors will avoid merging or closing those outright, and instead mar= k them as "pending", so that these can be brought to the attention= of the larger group. If no additional discussion happens on these, the merg= e or close action will be taken in 7 days. Note for this first round we are = setting the deadline for the issues below as Dec 11th due to the US holiday = and the fact that this is the first time using this process.

"Pe= nding Merge"
When specific text is proposed in a PR (by anyone, not = limited to the editors), and the editors believe this text reflects the cons= ensus of the working group, this marks that the PR will be merged in 7 days = unless there is a clear alternative proposal accepted by the working group.<= br>
"Pending Close"
When the editors believe an issue no lon= ger needs discussion, we'll mark it "Pending Close". The issue wil= l be closed in 7 days unless someone brings new information to the discussio= n. This tag is not applied to issues that will be closed by a specific pull = request.

There are two additional labels we will use to flag issues t= o the group.

"Needs Text"
The editors suggest this issue= needs additional text in the spec to clarify why this section is needed and= under what circumstances. Without a concrete proposal of text to be include= d in the spec, this section will be removed in a future update.

"= ;Postponed"
This issue can be reconsidered in the future with a more= concrete discussion but is not targeted for immediate concrete changes to t= he spec text. When used on its own, this label does not indicate that an iss= ue is targeted to be closed. An issue may also be marked "Pending Close= ", and this is used so that we can distinguish closed issues between di= scussions that have concluded or things that we may want to revisit in the f= uture. Remember that closed issues are not deleted and their contents are st= ill findable and readable, and that new issues can reference closed issues.<= br>
With these labels in mind, here are the list of issues and their stat= uses we were able to discuss on our last editor's call. The action on these = pending issues will be taken on Dec 11th to give the group enough time to re= view this list. For this first round, many of the issues are marked "Pe= nding Close" as we're looking for low hanging fruit to prune the list o= f issues down. In the future, you can expect to see more "Pending Merge= " issues as we're bringing proposed text to review by the WG.

Po= stponed:

* Generic claim extension mechanism
** https:= //github.com/ietf-wg-gnap/gnap-core-protocol/issues/131

Pending M= erge:

* Make access token mandatory for continuation API calls
** = https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129
Postponed and Pending Close:

* Fetchable Keys
** h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47
* Includi= ng OpenID Connect Claims
** https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/64
* Application communication with back-end<= br>** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/8= 2
* Additional post-interaction protocols
** https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/83

Pending Close:=
   
* HTTP PUT vs POST for rotating access tokens
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100<= br>* Use of hash with unique callback URL
** https://github.co= m/ietf-wg-gnap/gnap-core-protocol/issues/84
* Interaction considerati= ons
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issu= es/81
* Expanding dynamic reference handles
** https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/76
* Post interacti= on callback nonce
** https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/73
* Unique callback URIs
** https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/55
* Instance ident= ifier
** https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/46
* Requesting resources by reference
** https://= github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
* Mapping resour= ce references
** https://github.com/ietf-wg-gnap/gnap-core-pro= tocol/issues/35

---

Aaron Parecki

&nb= sp;

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

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

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

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

 

--B_3690127020_868984653-- From nobody Sun Dec 6 10:25:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C163A090D for ; Sun, 6 Dec 2020 10:25:55 -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 gCorcEht7wM7 for ; Sun, 6 Dec 2020 10:25:52 -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 06EC53A08FA for ; Sun, 6 Dec 2020 10:25:51 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id o8so11193546ioh.0 for ; Sun, 06 Dec 2020 10:25:51 -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=JBggsNVVSIZocYW+vN90W7kr/woRZUwOSrkB+MLlVwQ=; b=WxCXD7mvmI4jmuY0XVp76shmtgCIxCguQe3aMf3O5+d0zUiX1McGx/ON/AuDjWn7Gr l2EwDEiaQkUqwtj74EWffn+OiSJ9YSvUz3ESovw2s2vh0uPeY3fsNCQcV2XE4lrjm4U1 IntWiNPrjZZcLc/vdmZAo+YJCRzD90wfHWC/D7/rXlKhN6BTy2SkaVSDKxTBqe2Zkdv4 9AGn9y6IIkUr10xDLucnnJy/LHPIwBIkpqv5LmhR+JGiI1eQnpX9epjaLGp+xjBwng7G DvkMQuLX8Jxp6xsQi5koMaTwZduIVM+SdB8cRjuxe+prAbbr33V4SCQoLlyFJ61N2bPw A+0Q== 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=JBggsNVVSIZocYW+vN90W7kr/woRZUwOSrkB+MLlVwQ=; b=ZBC6InYwBE+stjefaY5fdu0CqL5+qJy2gBerXI9FFmZaMi9zv6hGlLXr9/fGelTWZf 94A8oRvBQrNinm2+P/4Y1n3hvQKnlXkDUsd/YLa2gtKoDzLn/obJV4BJpfUWk3CZOAjR IHYfCc2zhLUv5xmcwd6Bk6dsitp007mrLpmjby+SSUgWvVV0ZyVis113Qu8O6fVY9I9V 2mpMpuO2srR7ajstIwLQnV+GpwYCcDC506r+G6FTUJXCLMvoNbYKLfZv4U2kuVYK2qQ3 97x18QKV5YjBp/wGfBoOfZT2PY5WQq93D1GuG+qqsa1NU/THjpmNqR7Ukp8/u8G4UHZc RUhw== X-Gm-Message-State: AOAM5307mgQyAQTl235yFa5uxLWAy5eWFL3rS3WxMPKiYt3xQJTcAv7U sRqxQKbc2n18QXYB/ZQHyoMdvnoQ6xsLi9Kgg1Q= X-Google-Smtp-Source: ABdhPJyibHXT+3kXKorJ5vPye0ttzWECdkEp1i9UIb1v5FneCGYXGXgIDhfxDBeT1pDlFgYAf3eQwHVmTlvOqOV/wC8= X-Received: by 2002:a02:5148:: with SMTP id s69mr17158860jaa.8.1607279151014; Sun, 06 Dec 2020 10:25:51 -0800 (PST) MIME-Version: 1.0 References: <80EEA99F-3BCD-4FE9-9441-6D5EF4A606D9@gmail.com> <505DC510-2210-4097-AAFC-B321992555DA@mit.edu> <45958447-4336-4CB3-BB4C-36E948474390@gmail.com> In-Reply-To: <45958447-4336-4CB3-BB4C-36E948474390@gmail.com> From: Fabien Imbault Date: Sun, 6 Dec 2020 19:25:38 +0100 Message-ID: To: Yaron Sheffer Cc: Aaron Parecki , GNAP Mailing List , Justin Richer Content-Type: multipart/alternative; boundary="000000000000d9e4fb05b5cfd627" Archived-At: Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues 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, 06 Dec 2020 18:25:55 -0000 --000000000000d9e4fb05b5cfd627 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Yaron Yes we'll send a recap of all issues that need text. In case no one stands up and provide a proposal, those issues will indeed be closed. Fabien Le dim. 6 d=C3=A9c. 2020 =C3=A0 18:17, Yaron Sheffer a =C3=A9crit : > Regarding issues being closed with =E2=80=9Cneeds text=E2=80=9D, I don=E2= =80=99t think people are > going to scour the closed issues looking for interesting stuff =F0=9F=98= =8A. As I > said in the past, nobody cares for closed issues. > > > > Instead, I suggest to take these issues to the list and ask people to > provide text. If nobody does, say within a week, close the issue. > > > > Thanks, > > Yaron > > > > *From: *Aaron Parecki > *Date: *Friday, December 4, 2020 at 00:14 > *To: *GNAP Mailing List > *Cc: *Fabien Imbault , Yaron Sheffer < > yaronf.ietf@gmail.com>, Justin Richer > *Subject: *Re: [GNAP] GNAP Editors' Use of GitHub Issues > > > > Thanks for all the discussion around this so far. On our editors call > yesterday we talked about the "Postponed" label and have a new solution > that hopefully addresses the feedback from this discussion. > > > > The high-level goal with the "Postponed" label was to be able to triage > issues quickly while also making it clear that closing an issue doesn't > mean we are rejecting the topic of the issue. The "Postponed" label clear= ly > didn't communicate that intent. We will delete the label and instead > replace our use of it with both: > > > > * Leaving an issue open and adding it to a milestone for the next upcomin= g > IETF meeting > > * Closing an issue and adding the "Needs Text" label > > > > Adding an issue to the milestone of the next meeting will give us a > timeline for making sure we come back to that issue, avoiding leaving a l= ot > of hanging issues open with no clear path to move forward. Closing an iss= ue > with the "Needs Text" label indicates that there is nothing concrete to d= o > with the issue at the moment, but if someone would like to propose specif= ic > text, the issue can be re-opened and discussed further. > > > > Justin and Fabien, feel free to chime in to clarify if needed! > > > > - Aaron > > > > > > On Mon, Nov 30, 2020 at 9:29 AM Justin Richer wrote: > > With the editor hat on: > > > > A new spec like this is exciting work, and it=E2=80=99s inevitably going = to bring > in lots of ideas of what it could do and what it could incorporate. These > ideas are extremely valuable as they are what push new work into the real= ms > of innovation and possibility and out of the status quo from which it > sprang. But there=E2=80=99s a downside to this stream of ideas: most of t= hem aren=E2=80=99t > solid enough to incorporate in any way. They=E2=80=99re just loose ideas = that maybe > we want to consider, but they don=E2=80=99t have anything we can turn to = and say > =E2=80=9Cwe should build that=E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t b= uild that=E2=80=9D since there isn=E2=80=99t any > =E2=80=9Cthat=E2=80=9D to build. > > > > The editors have found that many of the issues currently filed seem to fi= t > into this category. There might be an interesting idea in there, but > without something specific to tie the idea to, we don=E2=80=99t have a lo= t to work > with as editors, and there are a lot of other items that the group needs = to > decide and fix first. It=E2=80=99s an issue of triage. > > > > The goal of the =E2=80=9CPostponed=E2=80=9D tag, as I understand how we= =E2=80=99re using it, is to > tag issues that might need some future discussion, but we aren=E2=80=99t = there yet. > Something tagged as =E2=80=9CPostponed=E2=80=9D but left open long term w= as meant to flag > it as an important detail we should get back to, when we can. Something > tagged =E2=80=9CPostponed=E2=80=9D and closed was meant to flag it as som= ething we might > want to revisit, but only when we=E2=80=99ve got something concrete to wo= rk > against. It=E2=80=99s not meant to say that the group has decided not to = do it, > it=E2=80=99s meant as a way to acknowledge the input and potentially tie = back to it > in the future, even if the issue got closed. > > > > It seems like the terminology of =E2=80=9CPostponed=E2=80=9D didn=E2=80= =99t quite capture that > intent, and honestly it might not be the best tool for us to use here. I > think we we can work with the idea of IETF meeting-based milestones, as h= as > been suggested by several people. The important outcome is that we don=E2= =80=99t > create a process that=E2=80=99s susceptible to getting buried in =E2=80= =9Cwouldn=E2=80=99t it be > nice if=E2=80=A6=E2=80=9D sentiments to the detriment of forward progress= on a functioning > protocol. Right now, we=E2=80=99ve got a lot of items that amount to poss= ible > future branches, and while we shouldn=E2=80=99t simple forget them, we sh= ouldn=E2=80=99t be > focusing energy on them until someone is able to take the effort to explo= re > that branch. At such a time, we can open a new issue and PR=E2=80=99s for= that, and > link back to these historical artifacts for background and context. By > tying such issues to an IETF meeting milestone, we can put some boundarie= s > on items to keep them from languishing. When the milestone comes up, we c= an > evaluate if there=E2=80=99s something to look at yet or not. > > > > =E2=80=94 Justin > > > > On Nov 27, 2020, at 4:03 AM, Fabien Imbault > wrote: > > > > Hi there, > > > > One of the potential problems we'd like to avoid is to have an ever > growing list of open issues that we never close. > > > > The idea of having milestones (e.g. IETF110) might be a complementary way > of managing priorities. > > > > Editors will revert back to the list after the US vacation days. > > > > Cheers, > > Fabien > > > > On Thu, Nov 26, 2020 at 1:26 AM Tom Jones > wrote: > > i agree - drop postponed - if you can't say till when, then close. Issues > can always be added by anyone at anytime. > > Peace ..tom > > > > > > On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer > wrote: > > Commenting on the proposed process (chair hat off): > > > > I think =E2=80=9Cpostponed=E2=80=9D issues should not be closed. Once som= ething is closed, > we should be reasonably confident that it is resolved for good. People > rarely search through closed issues. > > > > Moreover, IMO the label =E2=80=9Cpostponed=E2=80=9D is not actionable. In= stead, I suggest > to mark such issues with future milestones, e.g. =E2=80=9CIETF110=E2=80= =9D, meaning that at > this time we will review the issue. Otherwise, the =E2=80=9Cpostponed=E2= =80=9D issues will > probably suffer the destiny of all =E2=80=9Clow priority=E2=80=9D issues = =E2=80=93 they will be > ignored for months and eventually closed en masse. See [1] for GitHub > milestones. > > > > Otherwise I am fine with the rest of the process. > > > > Thanks, > > Yaron > > > > [1] > https://docs.github.com/en/free-pro-team@latest/github/managing-your-work= -on-github/about-milestones > > > > > > *From: *TXAuth on behalf of Aaron Parecki < > aaron@parecki.com> > *Date: *Wednesday, November 25, 2020 at 18:37 > *To: *GNAP Mailing List > *Subject: *[GNAP] GNAP Editors' Use of GitHub Issues > > > > The editors met yesterday to discuss the issues that were pulled out of > the previous draft text and document a process for how to resolve these a= nd > future issues. We would like to explain how we plan on using labels on > GitHub issues to keep track of discussions and keep things moving. > > When there are substantive issues or pull requests, the editors will avoi= d > merging or closing those outright, and instead mark them as "pending", so > that these can be brought to the attention of the larger group. If no > additional discussion happens on these, the merge or close action will be > taken in 7 days. Note for this first round we are setting the deadline fo= r > the issues below as Dec 11th due to the US holiday and the fact that this > is the first time using this process. > > "Pending Merge" > When specific text is proposed in a PR (by anyone, not limited to the > editors), and the editors believe this text reflects the consensus of the > working group, this marks that the PR will be merged in 7 days unless the= re > is a clear alternative proposal accepted by the working group. > > "Pending Close" > When the editors believe an issue no longer needs discussion, we'll mark > it "Pending Close". The issue will be closed in 7 days unless someone > brings new information to the discussion. This tag is not applied to issu= es > that will be closed by a specific pull request. > > There are two additional labels we will use to flag issues to the group. > > "Needs Text" > The editors suggest this issue needs additional text in the spec to > clarify why this section is needed and under what circumstances. Without = a > concrete proposal of text to be included in the spec, this section will b= e > removed in a future update. > > "Postponed" > This issue can be reconsidered in the future with a more concrete > discussion but is not targeted for immediate concrete changes to the spec > text. When used on its own, this label does not indicate that an issue is > targeted to be closed. An issue may also be marked "Pending Close", and > this is used so that we can distinguish closed issues between discussions > that have concluded or things that we may want to revisit in the future. > Remember that closed issues are not deleted and their contents are still > findable and readable, and that new issues can reference closed issues. > > With these labels in mind, here are the list of issues and their statuses > we were able to discuss on our last editor's call. The action on these > pending issues will be taken on Dec 11th to give the group enough time to > review this list. For this first round, many of the issues are marked > "Pending Close" as we're looking for low hanging fruit to prune the list = of > issues down. In the future, you can expect to see more "Pending Merge" > issues as we're bringing proposed text to review by the WG. > > Postponed: > > * Generic claim extension mechanism > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/131 > > Pending Merge: > > * Make access token mandatory for continuation API calls > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 > > Postponed and Pending Close: > > * Fetchable Keys > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/47 > * Including OpenID Connect Claims > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64 > * Application communication with back-end > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82 > * Additional post-interaction protocols > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 > > Pending Close: > > * HTTP PUT vs POST for rotating access tokens > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/100 > * Use of hash with unique callback URL > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 > * Interaction considerations > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 > * Expanding dynamic reference handles > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/76 > * Post interaction callback nonce > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/73 > * Unique callback URIs > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 > * Instance identifier > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46 > * Requesting resources by reference > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/36 > * Mapping resource references > ** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 > > --- > > Aaron Parecki > > https://aaronparecki.com > > > > -- TXAuth mailing list TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > --000000000000d9e4fb05b5cfd627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Yaron

= Yes we'll send a recap of all issues that need text.=C2=A0

In case no one stands up and provide= a proposal, those issues will indeed be closed.
Fabien=C2=A0

Le dim. 6 d=C3=A9c. 2020 =C3=A0 = 18:17, Yaron Sheffer <yaronf.ie= tf@gmail.com> a =C3=A9crit=C2=A0:

Regarding issues being closed with =E2=80=9Cneeds text=E2=80=9D,= I don=E2=80=99t think people are going to scour the closed issues looking = for interesting stuff =F0=9F=98=8A. As I said in the past, nobody cares for closed is= sues.

=C2=A0

Instead, I suggest to take these issues to the list and a= sk people to provide text. If nobody does, say within a week, close the iss= ue.

=C2=A0

Thanks,

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

=C2=A0

From: Aaron = Parecki <aaron@parecki.com>
Date: Friday, December 4, 20= 20 at 00:14
To: GNAP Mailing List <txauth@ietf.org>
= Cc: Fabien Imbault <fabien.imbault@gmail.com>, Yaron Sh= effer <yaronf.ietf@gmail.com>, Justin Richer <jricher@mit.edu<= /a>>
Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issue= s

Thanks for all the discussion ar= ound this so far. On our editors call yesterday we talked about the "P= ostponed" label and have a new solution that hopefully addresses the f= eedback from this discussion.

=C2=A0

=C2=A0

With the editor hat on:=

=C2=A0

A new spec like this is exciting work, and it=E2=80=99s inev= itably going to bring in lots of ideas of what it could do and what it coul= d incorporate. These ideas are extremely valuable as they are what push new= work into the realms of innovation and possibility and out of the status q= uo from which it sprang. But there=E2=80=99s a downside to this stream of i= deas: most of them aren=E2=80=99t solid enough to incorporate in any way. T= hey=E2=80=99re just loose ideas that maybe we want to consider, but they do= n=E2=80=99t have anything we can turn to and say =E2=80=9Cwe should build t= hat=E2=80=9D or =E2=80=9Cwe shouldn=E2=80=99t build that=E2=80=9D since the= re isn=E2=80=99t any =E2=80=9Cthat=E2=80=9D to build.=C2=A0

=C2=A0

The editors have found that many of the issues currently= filed seem to fit into this category. There might be an interesting idea i= n there, but without something specific to tie the idea to, we don=E2=80=99= t have a lot to work with as editors, and there are a lot of other items th= at the group needs to decide and fix first. It=E2=80=99s an issue of triage= .

=C2=A0

The goal of the =E2=80=9CPostponed=E2= =80=9D tag, as I understand how we=E2=80=99re using it, is to tag issues th= at might need some future discussion, but we aren=E2=80=99t there yet. Some= thing tagged as =E2=80=9CPostponed=E2=80=9D but left open long term was mea= nt to flag it as an important detail we should get back to, when we can. So= mething tagged =E2=80=9CPostponed=E2=80=9D and closed was meant to flag it = as something we might want to revisit, but only when we=E2=80=99ve got some= thing concrete to work against. It=E2=80=99s not meant to say that the grou= p has decided not to do it, it=E2=80=99s meant as a way to acknowledge the = input and potentially tie back to it in the future, even if the issue got c= losed.

=C2=A0<= /u>

It seems like the terminology of = =E2=80=9CPostponed=E2=80=9D didn=E2=80=99t quite capture that intent, and h= onestly it might not be the best tool for us to use here. I think we we can= work with the idea of IETF meeting-based milestones, as has been suggested= by several people. The important outcome is that we don=E2=80=99t create a= process that=E2=80=99s susceptible to getting buried in =E2=80=9Cwouldn=E2= =80=99t it be nice if=E2=80=A6=E2=80=9D sentiments to the detriment of forw= ard progress on a functioning protocol. Right now, we=E2=80=99ve got a lot = of items that amount to possible future branches, and while we shouldn=E2= =80=99t simple forget them, we shouldn=E2=80=99t be focusing energy on them= until someone is able to take the effort to explore that branch. At such a= time, we can open a new issue and PR=E2=80=99s for that, and link back to = these historical artifacts for background and context. By tying such issues= to an IETF meeting milestone, we can put some boundaries on items to keep = them from languishing. When the milestone comes up, we can evaluate if ther= e=E2=80=99s something to look at yet or not.

=C2=A0

=C2=A0=E2=80=94 Justin



On Nov 27, 2020, at 4:03 AM, Fabie= n Imbault <fabien.imbault@gmail.com> wrote:

=C2=A0

Hi there,=C2=A0

=C2=A0

One of the poten= tial problems we'd like to avoid is to have an ever growing list of ope= n issues that we never close.=C2=A0

=C2=A0

The i= dea of having milestones (e.g. IETF110) might be a complementary way of man= aging priorities.

=C2=A0

Editors=C2=A0will rever= t back to the list after the US vacation days.

=

=C2=A0

Cheers,

Fabien<= /u>

=C2=A0

On Thu, Nov 26, 2020 at 1:26 AM Tom Jones &l= t;thomasclinganjones@gmail.com> wrote:

i agree - drop postponed=C2=A0- if you can't say till when, th= en close. Issues can always be added by anyone at anytime.

Peace ..tom

=C2= =A0

=C2=A0

On Wed, Nov 25, 2020 at 10:27 AM Yaron Sheffer <= ;yaronf.ietf@gmail.com> wrote:

C= ommenting on the proposed process (chair hat off):

=C2=A0

I think =E2= =80=9Cpostponed=E2=80=9D issues should not be closed. Once something is clo= sed, we should be reasonably confident that it is resolved for good. People= rarely search through closed issues.

=C2=A0

Moreover, IMO the label = =E2=80=9Cpostponed=E2=80=9D is not actionable. Instead, I suggest to mark s= uch issues with future milestones, e.g. =E2=80=9CIETF110=E2=80=9D, meaning = that at this time we will review the issue. Otherwise, the =E2=80=9Cpostpon= ed=E2=80=9D issues will probably suffer the destiny of all =E2=80=9Clow pri= ority=E2=80=9D issues =E2=80=93 they will be ignored for months and eventua= lly closed en masse. See [1] for GitHub milestones.

=C2=A0

Otherwise I= am fine with the rest of the process.

=C2=A0

Thanks,

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

=C2=A0

[1] https://docs.= github.com/en/free-pro-team@latest/github/managing-your-work-on-github/abou= t-milestones

=C2=A0

=C2=A0

From: TXAuth <txauth-bounces@ietf.org> on be= half of Aaron Parecki <aaron@parecki.com>
Date: Wednesda= y, November 25, 2020 at 18:37
To: GNAP Mailing List <txauth@iet= f.org>
Subject: [GNAP] GNAP Editors' Use of GitHub Iss= ues

=C2=A0=

The editors met yesterday to discuss the issues that were pulled out of th= e previous draft text and document a process for how to resolve these and f= uture issues. We would like to explain how we plan on using labels on GitHu= b issues to keep track of discussions and keep things moving.

When t= here are substantive issues or pull requests, the editors will avoid mergin= g or closing those outright, and instead mark them as "pending", = so that these can be brought to the attention of the larger group. If no ad= ditional discussion happens on these, the merge or close action will be tak= en in 7 days. Note for this first round we are setting the deadline for the= issues below as Dec 11th due to the US holiday and the fact that this is t= he first time using this process.

"Pending Merge"
When = specific text is proposed in a PR (by anyone, not limited to the editors), = and the editors believe this text reflects the consensus of the working gro= up, this marks that the PR will be merged in 7 days unless there is a clear= alternative proposal accepted by the working group.

"Pending C= lose"
When the editors believe an issue no longer needs discussion,= we'll mark it "Pending Close". The issue will be closed in 7= days unless someone brings new information to the discussion. This tag is = not applied to issues that will be closed by a specific pull request.
There are two additional labels we will use to flag issues to the group.<= br>
"Needs Text"
The editors suggest this issue needs addit= ional text in the spec to clarify why this section is needed and under what= circumstances. Without a concrete proposal of text to be included in the s= pec, this section will be removed in a future update.

"Postpone= d"
This issue can be reconsidered in the future with a more concret= e discussion but is not targeted for immediate concrete changes to the spec= text. When used on its own, this label does not indicate that an issue is = targeted to be closed. An issue may also be marked "Pending Close"= ;, and this is used so that we can distinguish closed issues between discus= sions that have concluded or things that we may want to revisit in the futu= re. Remember that closed issues are not deleted and their contents are stil= l findable and readable, and that new issues can reference closed issues.
With these labels in mind, here are the list of issues and their stat= uses we were able to discuss on our last editor's call. The action on t= hese pending issues will be taken on Dec 11th to give the group enough time= to review this list. For this first round, many of the issues are marked &= quot;Pending Close" as we're looking for low hanging fruit to prun= e the list of issues down. In the future, you can expect to see more "= Pending Merge" issues as we're bringing proposed text to review by= the WG.

Postponed:

* Generic claim extension mechanism
**= https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/issues/131

Pending Merge:

* Make access toke= n mandatory for continuation API calls
** https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129

= Postponed and Pending Close:

* Fetchable Keys
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/47
* Including OpenID Connect Claims
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/64
* Application communication with back-end
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/82
* Additional post-interaction protocols
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83

Pending Close:
=C2=A0 =C2=A0
* HTTP PUT vs POST for rotatin= g access tokens
** https://github.co= m/ietf-wg-gnap/gnap-core-protocol/issues/100
* Use of hash with uniq= ue callback URL
** https://github.com= /ietf-wg-gnap/gnap-core-protocol/issues/84
* Interaction considerati= ons
** https://github.com/ietf-wg-gna= p/gnap-core-protocol/issues/81
* Expanding dynamic reference handles=
** https://github.com/ietf-wg-gnap/g= nap-core-protocol/issues/76
* Post interaction callback nonce
** = https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/73
* Unique callback URIs
** https://github.com/ietf-wg-gnap/gnap-core-protocol/issues= /55
* Instance identifier
** h= ttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/46
* Reques= ting resources by reference
** https:= //github.com/ietf-wg-gnap/gnap-core-protocol/issues/36
* Mapping res= ource references
** https://github.co= m/ietf-wg-gnap/gnap-core-protocol/issues/35

=

---

Aaron Parecki

= =C2=A0

-- TXAuth mailing list TXAuth@ietf.org https://www.ie= tf.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/t= xauth

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

=C2=A0

--000000000000d9e4fb05b5cfd627-- From nobody Mon Dec 7 03:46:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C463A1343 for ; Mon, 7 Dec 2020 03:46:52 -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 WoLwP9Xlp0S8 for ; Mon, 7 Dec 2020 03:46:51 -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 4292B3A133F for ; Mon, 7 Dec 2020 03:46:51 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id y5so13057501iow.5 for ; Mon, 07 Dec 2020 03:46:51 -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=Kir2ADDSVUq+2sMrzOjxrAa+2deTnoDcSK1vU0xyK6g=; b=OygTzKXgaC+/pmdG21/XuQwiXbUrETQd/6HlBEQ48VnJVeSn4LojfTkvHPvRUZuKTu /WXVetoXznAP33tgoFQ4Fn1yXTe1+EZlXNHK0KdSVx+dnCMLBVeUGyrPRGvXdPFiavU9 w9BgSUbQIAJEi0/8fEIgqOtHM4cwTtD6zQ3mYSYKFrQD+1XC0B6I54u7Uv9XJwtKXaTT np0qiDFxqLVfcZFr1gB1SZqN0dxDt+4wiDam9/daL6rNZUnTEcSVC9OzDIXsYgcnYf/D n8XbVUjATYH7gWzp+NLX5ex25a0bndZd/0V1bA9fT3NV0VY4DDG+QxMQItfCEH4qFTLD 6P8g== 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=Kir2ADDSVUq+2sMrzOjxrAa+2deTnoDcSK1vU0xyK6g=; b=eoXOWn0TaKyF/6GwLXnJ/T9UwBvRCkMLiBoC4twnLoWczsUBfBFbGzc/wLtxx03SdO 3FTlnd4TsgRCmTyx9utg/D50bnStKuV3EvbwVFqSAe7dkt8YElk9W96fp4FFWluuZh3J ZEEbbnaJsrawXNILgAks/Wkbkg6J46IabJk+f13XXfX7ZtjMdH9gVrT3Pi/zPlIIKRnE o6L4ybiROaaqXcEYaRyQVVdG/e3nsf8OiBoOn0JvDFrNuG7N6DugjXF4NJGQo9Ftxemq CPspvFsGVnwrBmz6FPXUvIT25Km3G3vP5s28GVBq6eGrUMj2S/CnfguWoUPCFy+aRGf9 cU1g== X-Gm-Message-State: AOAM531Dpg4ZG1xnaUo0kZwAMpeTYQZZvlEbTddRWBdRRSKU1PIbEinx iRG8lfCPBXAA6EkNu3R5y17iaihYfJWqqEm17aujLpMBZRTyTw== X-Google-Smtp-Source: ABdhPJzJLCXVMCUwe4i9a54hWglDLddah3In75TdRS/vhCUSCQMs/Jb0jmqbwPtB3sI13L0qfKyKAPeNwq0r0g5iQ+c= X-Received: by 2002:a6b:dd13:: with SMTP id f19mr14625784ioc.74.1607341610213; Mon, 07 Dec 2020 03:46:50 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Mon, 7 Dec 2020 12:46:39 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b5a2c105b5de6149" Archived-At: Subject: [GNAP] Those issues need text 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, 07 Dec 2020 11:46:53 -0000 --000000000000b5a2c105b5de6149 Content-Type: text/plain; charset="UTF-8" Hello everyone, Following Yaron's advice, we'll regularly publish on the mailing list the list of issues that need text. Those issues relate to items that are not critical to the core of the spec (and so are not managed in priority by the editors, at the moment), but might be useful in some contexts. The reason for "need text" is that we feel there's significant work to be done before those issues are likely to be included. Note that any contribution would have to be reviewed by the editors and the working group (and therefore is not guaranteed to pass as is), according to the same process as usual. A contribution must include a text proposal (and thus shouldn't be limited to comments in the issue). Currently, we have 6 open issues marked "need text", available from https://github.com/ietf-wg-gnap/gnap-core-protocol/labels/Needs%20Text issue 99: Updating and reading access tokens issue 98: Reading the state of a request issue 83: Additional post-interaction protocols issue 82: Application communication with back-end issue 64: Including OpenID Connect claims issue 47: Fetchable keys If there is no contribution, the editors will assume there's no significant interest and will close the issue (which can always be reopened later if the situation changes). The label "pending close" specifically tags the issues (currently the last 4 in the list) that are likely to be closed at the end of the week (our standard timeframe for status updates). More generally speaking, the weekly github update provides a summary of the activity, so that everyone can stay informed and step in. Best regards Fabien, for the editorial team --000000000000b5a2c105b5de6149 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,=C2=A0

Following Yaron&#= 39;s advice, we'll regularly publish on the mailing list the list of is= sues that need text. Those issues relate to items that are not critical to = the core of the spec (and so are not managed in priority by the editors, at= the moment), but might be useful in some contexts. The reason for "ne= ed text" is that we feel there's significant work to be done befor= e those issues are likely to be included.=C2=A0
Note that any con= tribution would have to be reviewed by the editors and the working group (a= nd therefore is not guaranteed=C2=A0to pass as is), according to the same p= rocess as usual. A contribution must=C2=A0include a text proposal (and thus= shouldn't be limited to comments in the issue).

Currently, we have 6 open issues marked "need text", available= from=C2=A0https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/labels/Needs%20Text

issue 99: Upd= ating and reading access tokens=C2=A0
issue 98: Reading the state of a r= equest=C2=A0
issue 83:=C2=A0Additional post-interaction protocols= =C2=A0
issue 82: Application communication with back-end=C2=A0
issue = 64:=C2=A0Including OpenID Connect claims=C2=A0
issue 47: Fetchable keys= =C2=A0

If there is no contribution, the editor= s will assume there's no significant interest and will close the issue = (which can always be reopened later if the situation changes). The label &q= uot;pending close" specifically tags the issues (currently the last 4 = in the list) that are likely to be closed at the end of the week (our stand= ard timeframe for status updates).

More generally = speaking, the weekly github update provides a summary of the activity, so t= hat everyone can stay informed and step in.=C2=A0

= Best regards
Fabien, for the editorial team
--000000000000b5a2c105b5de6149-- From nobody Mon Dec 7 07:19:25 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600B73A0E02 for ; Mon, 7 Dec 2020 07:19:23 -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 hqQ4XmHb70oi for ; Mon, 7 Dec 2020 07:19:21 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2913A0DF4 for ; Mon, 7 Dec 2020 07:19:21 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id t8so13683434iov.8 for ; Mon, 07 Dec 2020 07:19:21 -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=E3LzFrGeKLj/Y/QgHf4FsC7wyJIPjTKc77+vGfPGo6I=; b=D52J6uwsvKf5Sk0wYuTMQbkP95EQqLeFXqOCyosGdm+s/dxoedSQnqSsz0//NL3X6i /OmKGh+oLptbd0qwf0Rv3TzdqYSPVkrkzQ8nndaz6254qO6W2rQ2zir21fgI9VKQExEw aOyvQgjKQvv1HbFakXB8xTZjNenT437if1fCIb71ntqJFkuwxQK99R71Falaixz7NMPu nz46zoNRC8GZrukbsWNAtg6QQaq2oO77KwmaU0wxAnSVYPfC4wUKa3h4LwNwt2juU9y/ ANQdLC8Gr2D0uncARnVOdPmPks6fDaDeIBJ8n8nYZFMJh1+bpX43VFYwrzAn8Sm6SVG6 d9UQ== 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=E3LzFrGeKLj/Y/QgHf4FsC7wyJIPjTKc77+vGfPGo6I=; b=Huan8113vHkHQxdXWX+IR3kVcDIVsqCbHdJI1S/7DgIoLP0MNUKArB7pc1G4XGhfhm ANZxIicB7qied5IASeC56EDtIIAnbTazSBi/gu8I1TpTD8mEqACnJ6Gih3DYE5K1/yjD JNdJklqojVndIHAEpMvuKTiTwgw2tPx10JZ3CrNp8Lg8VZEjHbPtq4eWzvToHdkSoYNM Q2d1lYqN6DXzLZQEShDSnJnBrIhVWEr13QSaPQAfRwWCamaxHJHVUTY6W98RE8Bm2bv7 w//N28HXLVDAf3Lw+bdg3NG8VdkE44hjuyPlOZdL6RXudzM/SpZ0nYNDAiWUXeSbwALg QWyA== X-Gm-Message-State: AOAM532YrJB3Ntgx8c1/BEquUW1rfGhLMoGr9JjppsIRJnd6/+CsMHGo oNclRlTvugrRcEZMC9OgIepDf51hkdkwYkS6t+SeS70V+3qQCXKz X-Google-Smtp-Source: ABdhPJwvMPjgkHHOxw1GNMmAgq+ud1Squ5UNNMkpA2B06OVWwQL/I9YSK709aquNKkytSJ2FYJeqNOKywn64E59DOqg= X-Received: by 2002:a05:6602:214b:: with SMTP id y11mr9658346ioy.78.1607354360198; Mon, 07 Dec 2020 07:19:20 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Mon, 7 Dec 2020 16:19:09 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000aafb7105b5e159e8" Archived-At: Subject: [GNAP] Terminology proposal 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, 07 Dec 2020 15:19:23 -0000 --000000000000aafb7105b5e159e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, As an editor : a quick reminder that terminology issues will be discussed in the coming weeks, and we're expecting your inputs right now (according to the process previously sent on the mailing list). https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology The rest of this message is a proposal written in my own name, and doesn't involve discussions with the editors/chairs who might have different opinions. *Authorization Server (AS)* Manages the granting of privileges to a third-party client instance. If the RO consents to at least a part of what is requested, the AS issues an access token to the client. *My questions: * *- was else do we issue? (e.g. id claims, payment info, etc.) We could have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not = clear. I removed that for now.* *- there might potentially be several AS, currently we don=E2=80=99t reflec= t that anywhere. If would leave that as an open item, depending on what we end up doing in the spec* *Interact Server (IS)* - this is a new proposed term Manages the front-end interaction with the RO, in order to gather its consent. Depending on the deployment model and the privacy requirements, the IS may be a component of the AS, or may be distinct and managed by another party. Example : an IS usually involves a web interface accessed by RO through a web browser. Note : an IS is not always required, especially if the access is granted through automated policies. *Client* Requests privileges from the AS, and uses access tokens at the RS. This specification differentiates between a specific instance (the client instance, identified by its unique public key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of a single piece of client software.The AS determines which policies apply to a given client instance, including what it can request and on whose behalf. Example : a client can be a mobile application or a web application (the client software) that requires authorizations from the RO to retrieve content from various protected APIs. The client instance may for instance refer to a specific version of that client software. *See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance). * *Resource Server (RS)* Accepts valid access tokens from the client issued by the AS and serves protected resources on behalf of the RO. There could be multiple RSs protected by the AS that the client may call. Example : a RS is often composed of protected APIs that can be consumed by authorized client software. *Resource Owner (RO)* Authorizes the request to access a protected resource from the RS to the client. The RO may decide to remove its consent at any time. Note : the RO may be a physical person or may represent an organization. *End-user* =E2=80=93 this was previously Requesting Party RQ A physical person that operates and interacts with the client software. Note : the end-user may or may not be the same entity as the RO. *Access Token* A set of privileges delegated to the client instance for a specific end-user. An access token is created by the AS, consumed and verified by the RS, and issued to and carried by the client's end-user on behalf of the RO. The contents and format of the access token are opaque to the client. Example : JWT is a commonly used format. Note 1 : an access token generally has a limited duration, after which it may be refreshed at a regular interval. Note 2 : an access token may be revoked at any time by the RO. Note 3 : an access token may act as a capability or require an additional authentication by binding to a key *Grant* The process by which the client requests and is given delegated access to the RS by the AS through the authority of the RO. *Key* A public cryptographic binding a request to the holder of a private key. Access tokens and client instances can be associated with specific keys at a point in time. Note : a key can be rotated or revoked by its holder. The protocol supports the update of the key information. *Resource* A protected API served by the RS and accessed by the client if and only if access has been granted. Access to this resource is delegated by the RO as part of the grant process. *Subject Information* Information about a subject (usually a RO) that is returned directly to the client from the AS. Note : this information needs to be unique. *My questions : * *- probably we=E2=80=99d need to define subject* *Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+D= ictionary+Entry * *- might be useful to clarify the relationship to what identity providers do * Cheers Fabien --000000000000aafb7105b5e159e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,=C2=A0

As an editor : a = quick reminder that terminology=C2=A0issues will be discussed in the coming= weeks, and we're expecting your inputs right now (according to the pro= cess previously sent on the mailing list).
https://github.com/ietf-wg-gnap/gnap-core-protocol/wik= i/Terminology=C2=A0

The rest of this messa= ge is a proposal written in my own name, and doesn't involve discussion= s with the editors/chairs who might have different opinions.=C2=A0=C2=A0

=09 =09

Authorization Server (AS)

M= anages the granting of privileges to a third-party client instance. If the RO consents to at least a part of what is requested, the AS issues an acces= s token to the client.

= My questions:

<= i>- was else do we issue? (e.g. id claims, payment info, etc.) We could have mo= re than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I removed that for now= .

<= i>- there might potentially be several AS, currently we don=E2=80=99t reflect that anywhere. If would leave that as an open item, depending on what we en= d up doing in the spec

Interact Server (IS) - this is a new proposed term

<= font face=3D"arial, sans-serif">Manages the front-end interaction with the RO, in order to gather its consent. Depending on the deployment model and the privacy requirements, the IS may be a component of the AS, or may be distinct and managed by another party.

<= font face=3D"arial, sans-serif">Example : an IS usually involves a web interface accessed by RO through a web browser.

<= font face=3D"arial, sans-serif">Note : an IS is not always required, especially if the access is granted through= automated policies.

Client

<= font style=3D"">Requests privileges from the AS, and uses access tokens at the RS. This specificatio= n differentiates between a specific instance (the client instance, identified by its unique public key) and the software running the instance (the client software).=C2=A0For some kinds of client software, the= re could be many instances of a single piece of client software.The AS dete= rmines which policies apply to a given client instance, including what it can request and on whose behalf.

E= xample : a client can be a mobile application or a web application (the client software) that requires authorizations from the RO to retrieve content from various protected APIs. The client instance may for instance refer to a specific version of that client software.=

See on-going discussion : htt= ps://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance).

Resource Server (RS)

A= ccepts valid access tokens from the client issued by the AS and serves protected resources on behalf of the RO. There could be multiple RSs protected by the AS that the client may call.

E= xample : a RS is often composed of protected APIs that can be consumed by authorized client software.=C2=A0=C2=A0

<= b>Resource Owner (RO)

A= uthorizes the request to access a protected resource from the RS to the client. The R= O may decide to remove its consent at any time.

N= ote : the RO may be a physical person or may represent an organization.<= /font>

End-user =E2=80=93 this was previously Requesting Party RQ

A physical person that operates and interacts with the client software.

N= ote : the end-user may or may not be the same entity as the RO. <= /font>

<= b>Access Token

A set of privileges delegated to the client instance for a specific end-user.= An access token is created by the AS, consumed and verified by the RS, and issued to and carried by the client's end-user on behalf of the RO. The contents = and format of the access token are opaque to the client.

E= xample : JWT is a commonly used format.

N= ote 1 : an access token generally has a limited duration, after which it may be= refreshed at a regular interval.

N= ote 2 : an access token may be revoked at any time by the RO.

Note 3 : an access t= oken may act as a capability or require an additional authentication by bin= ding to a key=C2=A0

<= b>Grant

T= he process by which the client requests and is given delegated access to the RS by the AS through the authority of the RO.

<= b>Key

A public cryptographic binding a request to the holder of a private key. Access tokens and client instances can be associated with specific keys at a point in time.

N= ote : a key can be rotated or revoked by its holder. The protocol supports the update of the key information.

<= b>Resource

A protected API served by the RS and accessed by the client if and only if access has been granted. Access to this resource is delegated by the RO as part of the grant process.

<= b>Subject Information

I= nformation about a subject (usually a RO) that is returned directly to the client from the AS.

N= ote : this information needs to be unique.


My questions :

- probably we=E2=80=99d need to define subject

Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/S= ubject+Dictionary+Entry

- might be useful to clarify the relationship to what identity providers do=C2=A0



Cheers
Fabien

=


--000000000000aafb7105b5e159e8-- From nobody Mon Dec 7 08:11:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B2F3A15AA for ; Mon, 7 Dec 2020 08:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83a5YjtCp-Dv for ; Mon, 7 Dec 2020 08:11:42 -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 5424D3A1411 for ; Mon, 7 Dec 2020 08:11:41 -0800 (PST) Received: from [192.168.1.11] ([90.91.135.71]) by mwinf5d09 with ME id 1UBc2400H1Ybo4i03UBcry; Mon, 07 Dec 2020 17:11:37 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 07 Dec 2020 17:11:37 +0100 X-ME-IP: 90.91.135.71 To: Fabien Imbault Cc: GNAP Mailing List References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> From: Denis Message-ID: <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> Date: Mon, 7 Dec 2020 17:11:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4E58D5C8B715BC766CEED16C" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Quick review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:11:47 -0000 This is a multi-part message in MIME format. --------------4E58D5C8B715BC766CEED16C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, I have been quite long before responding to your email. The response took me occupied for a long while too. > Hi Denis, > > I've been thinking more about your feedback. Marked with [FI] in your > initial comments. > > We probably need to address your feedback early on, and make sure the > WG is fine with those. > Overall I believe we can achieve much of what you'd want regarding > privacy, without impacting too much the architecture. [Denis] I hope so (and cross my fingers). > Fabien > > On Wed, Oct 21, 2020 at 7:20 PM Fabien Imbault > > wrote: > > Hi Denis, > > The "many options" is only a temporary state, the goal was to > expose the decisions that need to be made to the mailing list. We > can quickly reduce to a manageable level by having focused > discussions. > > As for the remainder of your comments, the only item we considered > so far was one of principle: that privacy is an important goal of > the work. The rest of the focus was on taking the best out of XYZ > and XAuth. So incorporating the discussions that occurred just > before the focus group wasn't a goal. You can already see that > with regards to terminology, where insightful discussions occurred > but the paint was really very fresh. > > I find what you explain really interesting. It will need to be > analyzed in detail. The caveat is that we have less background > experience of what it means in practice (compared to the current > document vs OAuth2). > I guess it will require a bit of experimentation, to avoid corner > cases. > > More specific comments/questions coming later :-) > > Fabien > > > Le mer. 21 oct. 2020 à 17:58, Denis > a écrit : > > Hi, > > I haven't read all the document in details, but I have browsed > through it: this took me about 3 hours. > As it is, I don't consider that the current text (more than > 100 pages !) is a "good starting point". > > The less that I can say is that the document is far from being > crystal clear, is too complex and includes so many options > (without indicating which parameters are required and which > ones are optional) that it will be impossible to claim that > an implementation complies with it. > > In addition, it is unfortunate that many of the discussions we > have had on the mailing list have not been incorporated by the > design team. > > Here are some comments: > > 1.An overview is missing since the various features are only > being discovered while reading the document. > > 2.A key question that might interest a reader is the > following: what are the common points and the main differences > with OAuth ? > > 3.The whole document is "AS centric" while it should also be > "RS centric". These two concepts have been explained on the > mailing list. > > [FI] indeed it is centered around the AS. What's your proposition if > we were to change the text? > Notice that most business scenarios today require an AS centric > approach. We've seen from previous discussion that it doesn't preclude > from enabling more privacy. [Denis] As you write "business scenarios today require an AS centric approach" as long as a single company supporting one AS and several RSs is involved. On the Internet, some servers are already proposing the intermediation of a several identity providers. This should be generalized. You raised a good question: What's your proposition if we were to change the text? Page 9. The current text is:    *  (1) The RC attempts to call the RS (Section 10.4) to determine what access is needed.  The RS informs the RC that access can be granted through the AS.        Note that for most situations, the RC already knows which AS to talk to and which kinds of access it needs.    *  (2) The RC requests access at the AS (Section 2).    *  (3) The AS processes the request and determines what is needed to fulfill the request.  The AS sends its response to the RC (Section 3). Section 10.4 is the last section just before the acknowledgement section and refers to a "GNAP endpoint" while this term is not used before. I guess that this reference is incorrect. While I don't intend to cover all possible scenarios, I would detail the first steps differently:    *  (1)    If the RC has never called the RS before, the RC calls the RS to determine which ASs are trusted by that RS                and which claim types are requested for the operation he wishes to perform. If the RC knows the language preference(s)                of the end-user they are indicated in this call.    *  (2)    The RS responds by indicating one or more ASs and for each AS which claim types are requested.                 The RS also indicates, in a "display" field, for each attribute type the reason(s) for requesting it.                 This information is intended to be displayed to the end-user by the RC, if the end-user is interested to know it.    *  (3)    The end-user may choose to see the "display" field from the previous message in his favourite language and then chooses which AS(s) to call                 and gives his consent to call these ASs (or a subset of them) together for the set of a claim types requested (or a subset of theses claim types).                 The RC memorises the *user consent* and the choices made by the user for that RS and for the requested operation.                 Note: the end-user MUST be able to know which kind of end-user identifier claim is requested by an AS, in particular whether it is globally unique,                            unique to the AS only, unique to the RS only or ephemeral (valid for that RS during a session with the AS). This has implications with respect to privacy.    *  (4)    The RC authenticates to the AS(s).    *  (5)    The RC requests one or more access tokens to each selected AS that should contain the selected set of claim types.                 The target RS may be either a URL in clear text or may be a set of bits that is not meaningful to the AS and that will not be generated twice by the same RC.                 The later case allows to hide the identity of the RS to the AS, but still allows the RC to target the access token to the appropriate RS URL. The later case                 prevents the AS to act as Big Brother.    *  (6)    Each AS sends back one or more access tokens to the RC.     * (7)    The RC verifies that the claim types inserted within each access token correspond to the claim types that have been requested.                 If not, the access token may be discarded. Note: In order to be able to perform that verification, access tokens are not opaque to the RC.                 If such a verification cannot be done, the RC may discard the access token.    *  (8)    The RC sends the access token(s) to the RS together with the operation its wishes to perform.    *  (9)    The RS determines if the access token(s) is (are) adequate for the operation by examining the access token(s).    *  (10)  If the access token(s) is (are) accepted, the RS provides a response to the RC for the requested operation. The process may be optimized with the following step:     * (0)   The RC performs a look up in the table of previous operations performed by the user and :                     - if it finds the same operation for the same user for that RS associated with still valid access tokens, it goes to step (8).                     - if it finds the same operation for the same user for that RS associated with a no more valid access token, it fetches an updated access token and goes to step (7).                     - otherwise, it goes to step (1). One important explanation: RFC 6973 (Privacy Considerations for Internet Protocols) mentions: 7.2.  User Participation    a.  User control.  What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol ?           (...) 7.2.  User Participation d.  Preference expression.  Does the protocol provide ways for initiators to express individuals’ preferences to recipients or intermediaries with regard to the collection, use,                                                 or disclosure of their personal data? Steps (2) and step (3) are the responses to these two questions. > 4.The document only speaks about "_the_ AS", as if only one AS > would exist which is obviously not the case. >     The first access made to a RS shall be able to identify > which ASs are trusted by the RS. In addition, for each trusted > AS, the RS should be able >     to indicate which access rights are needed to perform > every operation possible at that stage. For any subsequent > stage, the RS may also indicate >     which attributes or access rights are needed to perform > each subsequent operation. > > [FI] There's also two related questions : a) do we allow multiple-AS > scenarios? b) do we allow other AS deployment options, and if so, how? > (like a personal AS on your phone). [Denis] My answer is option a). The previous response illustrates how to handle that case. I consider that an AS is a server (the "S" from "AS" tells it) and as such it cannot be on a phone. > 5."API’s documentation" versus "API discovery". Whereas the > API’s documentation is static and not necessarily up to date > or the RC software >     is not necessarily up to date, API discovery provides real > time information which is necessarily up to date. > >     There should be an API discovery mechanism for RSs. > > [FI] is that our job to do that? There are already existing discovery > mechanisms in the wild that people could use. [Denis] The current document includes a section 9 called "Discovery" (page 92). This section describes discovery functions for an AS only. In the same way, discovery functions for a RS could be described. In particular, whether an initial authentication to the RS is needed or not and, if not, which operations can be requested, which ASs are trusted by that RS and which claim types are requested for these operations. > >     Using an appropriate HTTP OPTIONS request, the RC should > be able to query the RS in order to know /at any point of time/: > > * the operations that can be done (i.e. which methods > are available on which data objects), and > * the access control characteristics associated with > each of these operations (i.e. which ASs are being > trusted by the RS > and what should be the incorporated into access > token(s) in terms of attributes types (and optionally > attribute values) > or in terms of capabilities (i.e. permissions granted). > > 6.The "user consent" phase has been ignored. It should be done > at the RS. Using information obtained from a RS, a RC should > be able >     to select which AS it wants to contact and explicitly > agree to request the mentioned attributes to that AS. > Alternatively, when the user consent phase >     is not done at the RS, it shall be done at the AS. > > [FI] To be discussed further. I believe an optional separate > Interaction Server solves this case, without disruption for standard > use cases (OAuth2 like) that are likely to remain. [Denis] See the scenario with the 10 steps above. I believe that there is no need for an optional separate Interaction Server. > > 7.The content and the format of access tokens shall not be > considered to be opaque to the RC so that the RC can inspect it. >     This is a matter of confidence to make sure for the RC > (and for the user) that no "extra" information has been > included by the AS into the access token. > > [FI] This might go a bit further than the GNAP's mandate (especially > if it becomes a mandatory requirement). But supposing we support > non-opaque tokens, > does it preclude supporting opaque tokens? It's just a different trust > model, which makes sense if people agree with your premises (previous > items), > but that are less relevant if people still consider the AS as the > central piece. Also one great thing with opaque tokens is that it > makes the system easier to upgrade > (you don't really care about what a token is). [Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for that RS during a session with the AS). I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number inside each access token. > One alternative way would be to allow RS call to AS for verification > (including revocation status) and include a checksum. [Denis]  The RC, i.e. not the RS, should be able to perform such verification before presenting the access token to the RS. So this alternative way would not work. > 8."Resource Owner (RO) : Authorizes the request from the RC to > the RS", full stop. The RO is associated with a RS, not with > an AS. >     The RS can know in advance with attributes or access > rights are needed to grant a given operation. > > [FI] ideally makes sense I think, but need to check the practical > implications. Related to terminology #6. [Denis] Fine. > 9.The model should allow the use of both Access Control Lists > and of Capabilities Lists. > > * Access control lists contain identifiers of users > and/or identifiers of users groups or identity claims > in relationship with an operation. > * Capabilities lists contains operations granted on > services within a RC. > >      As a consequence, access tokens may contain identifiers > of users and/or identity claims and/or identifiers of users > groups and/or capabilities. >     Whereas identifiers of users and/or identifiers of users > groups and/or identity claims may be managed by an AS > independently from RSs, >     this is not the case for capabilities where a RO > associated with a RS needs to interact with the AS either in > advance or in real time >     (which makes such mechanism much more complex). > > > [FI] We had several discussions on this topic, and I still consider > the current approach to be the right path. I don't think your scenario > is really more complex, > that's basically what people are doing when using a policy engine > (which can be as simple as casbin.org for > instance) to generate access tokens. > More fundamentally, ensuring least privilege using ACLs is known to be > a hard problem. [Denis]. I am wondering what you mean when you write "I still consider the current approach to be the right path". I do prefer ACLs, but capabilities is another possibility. I would have no problem if we say that capabilities are not supported by the model. :-) 10.In the case where access control lists are being used, there should be a possibility for a RC, for privacy reasons, to hide the identifier > >      of the RS to the AS (usually a URL) when requesting an > access token. A method able to support such feature has been > discussed extensively on the mailing list. > > [FI] depends on decision regarding previous item. [Denis] I don't understand why it would be related to the previous item. An access token can be targeted to a given RS (or a given service) irrespective whether it carries information usable for an ACL scheme or for a Capability scheme. > > 11.The text states: "Authorization Server (AS)Manages the > requested delegations for the RO". This is only one of two > possibilities. >      The interaction between a RO and an AS should be > considered as an option. If a RO needs to interact, for > privacy reasons, it should preferably >       interact with the RS only. > > [FI] The problem with working at the RS level is that it makes the > integration harder (we don't exactly know what people will implement). > As a consequence, I would be in favor of an optional separation of > that issue in an Interact Server, which could be distinct from the AS > to alleviate privacy concerns. [Denis] My point was/is about the quoted sentence: "Authorization Server (AS)  Manages the requested delegations for the RO" which is incorrect in the general case. Furthermore, interactions with a RO create delays in the protocol, so I am favouring situations where a RO does not need to interact at all, in order to obtain a better throughput. Anyway, I am not in favour of introducing a new entity like "an Interact Server". > > 12.The text states: "ResourceA protected API served by the RS > and accessed by the RC. Access to this resource is delegated > by the RO as part of the grant process". >       The second part of the sentence should be deleted since > a RO is not necessarily involved in the grant process. > > [FI] Yes, more generally we should check that we can deal with user = > RO (usually considered as the default case) and user != RO (not often > carefully designed). > I think the text already goes into much more details than OAuth2 for > this (cf sequences 1.4). [Denis] My preference is to use the term "end-user" for the entity interacting locally with the RC. > > 13.The text states: "Resource Client (RC, aka > "client")Requests tokens from the AS and uses tokens at the RS. >       An instance of the RC software is identified by its key, > which can be known to the AS prior to the first request". > >       This is confusing. The key does not necessarily identify > an instance of the RC software. >       An instance of the RC software uses a binding key which > (for privacy reasons) should be dynamic but which may > alternatively be static. > > [FI] The client instance solves those issues. Might need to update the > way it is described in the text. [Denis] Let us have a look at the text in a subsequent version. > 14.For privacy reasons, calls from an RS to an AS, such as > token introspection, should be avoided. > > [FI] Token introspection (as well as other aspects related to token > management) should be reviewed in depth, currently we don't solve many > of the problems we see in the OAuth world. > I don't believe calls from an RS to an AS should be avoided though, on > the contrary there might be an alternative to your proposal where the > RS could use a public AS endpoint for the revocation list. [Denis]  In the single sentence above, I am not proposing a scenario "where the RS could use a public AS endpoint for the revocation list". My belief is that revocation should not be handled at all, by using "short" validity periods for access tokens. By "short", I mean a duration of about 12 hours. > > 15.Section 2 deals with the parameters when making calls from > a RC to an AS. This section would need to be revisited. >       Hereafter are only some (of many) concerns about the > current text. The most important is to identify which > parameters shall be used >       and may be used when making a call to get an access token. > >      The text states: "resourcesDescribes the rights that the > RC is requesting for one or more access tokens to be used at > RS’s. >      Section 2.1". Then after: "Each object contains a "type" > property that determines the type of API that the RC is calling. >       (...)The value of this field is under the control of the AS. > > [FI] please provide your input to the terminology work.  [Denis] Would you be able to post to the list where we are now, or a link where we can have an overview of the current proposed definitions ? >      The value of this field should not be under the control > of the AS but of the RS. > > [FI] ultimately, the field needs to correspond to what the RS > provides, even if the AS is the one that generates the access token. > Your proposal is interesting but that would put more effort on the RS > side, with impacts on deployability. > > >      The text states: "actionsThe types of actions the RC will > take at the RS". This is needed when capabilities are being > used but not needed >      for the other cases. Revealing actions to an AS is > against the user's privacy. > > [FI] technically this could be any alias defined by the RS. Remember > we discussed RS hiding strategies (ex: concealed identifier) which > solve that issue.  [Denis] A key difference between an ACL scheme and a capability scheme is the following: *  for an ACL scheme, the AS does not need to have any prior relationship with the RS (which is an advantage from a privacy point of view). *  for a capability scheme, the capabilities needs to be defined by the RO of each RS, either prior to the time of the access token request  or at latest at the time of the access token request (which creates a delay). >      The text states: "locationsThe location of the RS as an > array of strings. These strings are typically URIs identifying > the location of the RS." > > >      It is typically URLs (not URIs) but it may also be > /service names/ so that an access token can be delegated by a > first RS to a second RS >      belonging to the same service without the need for the > first RS to request another access token. > > [FI] delegation from a RS to another is a topic in itself, yet to be > explored. I remember you sent various inputs on that, we might need to > review them in detail. [Denis] Using services names instead of URLs is not necessarily related to "delegation from a RS to another". If a RC can get such an access token, it may decide to send it to any RS belonging to that service at any point of time. So this is relevant for the simple case without considering "delegation from a RS to another RS". Denis > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --------------4E58D5C8B715BC766CEED16C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Fabien,

I have been quite long before responding to your email. The response took me occupied for a long while too.

Hi Denis, 

I've been thinking more about your feedback. Marked with [FI] in your initial comments.

We probably need to address your feedback early on, and make sure the WG is fine with those.
Overall I believe we can achieve much of what you'd want regarding privacy, without impacting too much the architecture.

[Denis] I hope so (and cross my fingers).


Fabien 

On Wed, Oct 21, 2020 at 7:20 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Denis,

The "many options" is only a temporary state, the goal was to expose the decisions that need to be made to the mailing list. We can quickly reduce to a manageable level by having focused discussions.

As for the remainder of your comments, the only item we considered so far was one of principle: that privacy is an important goal of the work. The rest of the focus was on taking the best out of XYZ and XAuth. So incorporating the discussions that occurred just before the focus group wasn't a goal. You can already see that with regards to terminology, where insightful discussions occurred but the paint was really very fresh. 

I find what you explain really interesting. It will need to be analyzed in detail. The caveat is that we have less background experience of what it means in practice (compared to the current document vs OAuth2).
I guess it will require a bit of experimentation, to avoid corner cases.

More specific comments/questions coming later :-) 

Fabien 


Le mer. 21 oct. 2020 à 17:58, Denis <denis.ietf@free.fr> a écrit :

Hi,

I haven't read all the document in details, but I have browsed through it: this took me about 3 hours.
As it is, I don't consider that the current text (more than 100 pages !) is a "good starting point".

The less that I can say is that the document is far from being crystal clear, is too complex and includes so many options
(without indicating which parameters are required and which ones are optional) that it will be impossible to claim that
an implementation complies with it.

In addition, it is unfortunate that many of the discussions we have had on the mailing list have not been incorporated by the design team.

Here are some comments:

1. An overview is missing since the various features are only being discovered while reading the document.

2. A key question that might interest a reader is the following: what are the common points and the main differences with OAuth ?

3. The whole document is "AS centric" while it should also be "RS centric". These two concepts have been explained on the mailing list.

[FI] indeed it is centered around the AS. What's your proposition if we were to change the text?
Notice that most business scenarios today require an AS centric approach. We've seen from previous discussion that it doesn't preclude from enabling more privacy.

[Denis] As you write "business scenarios today require an AS centric approach" as long as a single company supporting one AS and several RSs is involved.
On the Internet, some servers are already proposing the intermediation of a several identity providers. This should be generalized.

You raised a good question: What's your proposition if we were to change the text?

Page 9. The current text is:

   *  (1) The RC attempts to call the RS (Section 10.4) to determine what access is needed.  The RS informs the RC that access can be granted through the AS.
       Note that for most situations, the RC already knows which AS to talk to and which kinds of access it needs.
   *  (2) The RC requests access at the AS (Section 2).
   *  (3) The AS processes the request and determines what is needed to fulfill the request.  The AS sends its response to the RC (Section 3).

Section 10.4 is the last section just before the acknowledgement section and refers to a "GNAP endpoint" while this term is not used before.
I guess that this reference is incorrect.

While I don't intend to cover all possible scenarios, I would detail the first steps differently:

   *  (1)    If the RC has never called the RS before, the RC calls the RS to determine which ASs are trusted by that RS
               and which claim types are requested for the operation he wishes to perform. If the RC knows the language preference(s)
               of the end-user they are indicated in this call.

   *  (2)    The RS responds by indicating one or more ASs and for each AS which claim types are requested.
                The RS also indicates, in a "display" field, for each attribute type the reason(s) for requesting it.
                This information is intended to be displayed to the end-user by the RC, if the end-user is interested to know it.           

   *  (3)    The end-user may choose to see the "display" field from the previous message in his favourite language and then chooses which AS(s) to call
                and gives his consent to call these ASs (or a subset of them) together for the set of a claim types requested (or a subset of theses claim types).
                The RC memorises the user consent and the choices made by the user for that RS and for the requested operation.

                Note: the end-user MUST be able to know which kind of end-user identifier claim is requested by an AS, in particular whether it is globally unique,
                           unique to the AS only, unique to the RS only or ephemeral (valid for that RS during a session with the AS). This has implications with respect to privacy.

   *  (4)    The RC authenticates to the AS(s).

   *  (5)    The RC requests one or more access tokens to each selected AS that should contain the selected set of claim types.
                The target RS may be either a URL in clear text or may be a set of bits that is not meaningful to the AS and that will not be generated twice by the same RC.
                The later case allows to hide the identity of the RS to the AS, but still allows the RC to target the access token to the appropriate RS URL. The later case
                prevents the AS to act as Big Brother.

   *  (6)    Each AS sends back one or more access tokens to the RC.

    * (7)    The RC verifies that the claim types inserted within each access token correspond to the claim types that have been requested.
                If not, the access token may be discarded. Note: In order to be able to perform that verification, access tokens are not opaque to the RC.
                If such a verification cannot be done, the RC may discard the access token.

   *  (8)    The RC sends the access token(s) to the RS together with the operation its wishes to perform.

   *  (9)    The RS determines if the access token(s) is (are) adequate for the operation by examining the access token(s).

   *  (10)  If the access token(s) is (are) accepted, the RS provides a response to the RC for the requested operation.

The process may be optimized with the following step:

    * (0)   The RC performs a look up in the table of previous operations performed by the user and :

                    - if it finds the same operation for the same user for that RS associated with still valid access tokens, it goes to step (8).
                    - if it finds the same operation for the same user for that RS associated with a no more valid access token, it fetches an updated access token and goes to step (7).
                    - otherwise, it goes to step (1).

One important explanation: RFC 6973 (Privacy Considerations for Internet Protocols) mentions:

7.2.  User Participation

   a.  User control.  What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol ? 

          (...)

7.2.  User Participation

d.  Preference expression.  Does the protocol provide ways for initiators to express individuals’ preferences to recipients or intermediaries with regard to the collection, use,
                                                or disclosure of their personal data?

Steps (2) and step (3) are the responses to these two questions.

4. The document only speaks about "the AS", as if only one AS would exist which is obviously not the case.
    The first access made to a RS shall be able to identify which ASs are trusted by the RS. In addition, for each trusted AS, the RS should be able
    to indicate which access rights are needed to perform every operation possible at that stage. For any subsequent stage, the RS may also indicate
    which attributes or access rights are needed to perform each subsequent operation.

[FI] There's also two related questions : a) do we allow multiple-AS scenarios? b) do we allow other AS deployment options, and if so, how? (like a personal AS on your phone).

[Denis] My answer is option a). The previous response illustrates how to handle that case. I consider that an AS is a server (the "S" from "AS" tells it) and as such it cannot be on a phone.

5. "API’s documentation" versus "API discovery". Whereas the API’s documentation is static and not necessarily up to date or the RC software
    is not necessarily up to date, API discovery provides real time information which is necessarily up to date.

    There should be an API discovery mechanism for RSs.

[FI] is that our job to do that? There are already existing discovery mechanisms in the wild that people could use.

[Denis] The current document includes a section 9 called "Discovery" (page 92). This section describes discovery functions for an AS only.
In the same way, discovery functions for a RS could be described. In particular, whether an initial authentication to the RS is needed or not
and, if not, which operations can be requested, which ASs are trusted by that RS and which claim types are requested for these operations.


    Using an appropriate HTTP OPTIONS request, the RC should be able to query the RS in order to know at any point of time:

  • the operations that can be done (i.e. which methods are available on which data objects), and
  • the access control characteristics associated with each of these operations (i.e. which ASs are being trusted by the RS
    and what should be the incorporated into access token(s) in terms of attributes types (and optionally attribute values)
    or in terms of capabilities (i.e. permissions granted).

6. The "user consent" phase has been ignored. It should be done at the RS. Using information obtained from a RS, a RC should be able
    to select which AS it wants to contact and explicitly agree to request the mentioned attributes to that AS. Alternatively, when the user consent phase
    is not done at the RS, it shall be done at the AS.

[FI] To be discussed further. I believe an optional separate Interaction Server solves this case, without disruption for standard use cases (OAuth2 like) that are likely to remain.

[Denis] See the scenario with the 10 steps above. I believe that there is no need for an optional separate Interaction Server.


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
    This is a matter of confidence to make sure for the RC (and for the user) that no "extra" information has been included by the AS into the access token.

[FI] This might go a bit further than the GNAP's mandate (especially if it becomes a mandatory requirement). But supposing we support non-opaque tokens,
does it preclude supporting opaque tokens? It's just a different trust model, which makes sense if people agree with your premises (previous items),
but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade
(you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for
that RS during a session with the AS).

I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number
inside each access token.


One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum.

[Denis]  The RC, i.e. not the RS, should be able to perform such verification before presenting the access token to the RS. So this alternative way would not work.


8. "Resource Owner (RO) : Authorizes the request from the RC to the RS", full stop. The RO is associated with a RS, not with an AS.
    The RS can know in advance with attributes or access rights are needed to grant a given operation.

[FI] ideally makes sense I think, but need to check the practical implications. Related to terminology #6. 

[Denis] Fine.


9. The model should allow the use of both Access Control Lists and of Capabilities Lists.

  • Access control lists contain identifiers of users and/or identifiers of users groups or identity claims in relationship with an operation.
  • Capabilities lists contains operations granted on services within a RC.

     As a consequence, access tokens may contain identifiers of users and/or identity claims and/or identifiers of users groups and/or capabilities.
    Whereas identifiers of users and/or identifiers of users groups and/or identity claims may be managed by an AS independently from RSs,
    this is not the case for capabilities where a RO associated with a RS needs to interact with the AS either in advance or in real time
    (which makes such mechanism much more complex).


[FI] We had several discussions on this topic, and I still consider the current approach to be the right path. I don't think your scenario is really more complex,
that's basically what people are doing when using a policy engine (which can be as simple as casbin.org for instance) to generate access tokens. 
More fundamentally, ensuring least privilege using ACLs is known to be a hard problem.

[Denis]. I am wondering what you mean when you write "I still consider the current approach to be the right path". I do prefer ACLs, but capabilities is another possibility.
I would have no problem if we say that capabilities are not supported by the model. :-)

10. In the case where access control lists are being used, there should be a possibility for a RC, for privacy reasons, to hide the identifier

     of the RS to the AS (usually a URL) when requesting an access token. A method able to support such feature has been discussed extensively on the mailing list.

[FI] depends on decision regarding previous item. 

[Denis] I don't understand why it would be related to the previous item. An access token can be targeted to a given RS (or a given service)
irrespective whether it carries information usable for an ACL scheme or for a Capability scheme.


11. The text states: "Authorization Server (AS)  Manages the requested delegations for the RO". This is only one of two possibilities.
     The interaction between a RO and an AS should be considered as an option. If a RO needs to interact, for privacy reasons, it should preferably
      interact with the RS only.

[FI] The problem with working at the RS level is that it makes the integration harder (we don't exactly know what people will implement).
As a consequence, I would be in favor of an optional separation of that issue in an Interact Server, which could be distinct from the AS to alleviate privacy concerns.

[Denis] My point was/is about the quoted sentence: "Authorization Server (AS)  Manages the requested delegations for the RO" which is incorrect in the general case.
Furthermore, interactions with a RO create delays in the protocol, so I am favouring situations where a RO does not need to interact at all, in order to obtain a better throughput.
Anyway, I am not in favour of introducing a new entity like "an Interact Server".


12. The text states: "Resource  A protected API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process".
      The second part of the sentence should be deleted since a RO is not necessarily involved in the grant process.

[FI]  Yes, more generally we should check that we can deal with user = RO (usually considered as the default case) and user != RO (not often carefully designed).
I think the text already goes into much more details than OAuth2 for this (cf sequences 1.4). 

[Denis] My preference is to use the term "end-user" for the entity interacting locally with the RC.


13. The text states: "Resource Client (RC, aka "client")  Requests tokens from the AS and uses tokens at the RS. 
      An instance of the RC software is identified by its key, which can be known to the AS prior to the first request".

      This is confusing. The key does not necessarily identify an instance of the RC software.
      An instance of the RC software uses a binding key which (for privacy reasons) should be dynamic but which may alternatively be static.

[FI] The client instance solves those issues. Might need to update the way it is described in the text.

[Denis] Let us have a look at the text in a subsequent version.


14. For privacy reasons, calls from an RS to an AS, such as token introspection, should be avoided.

[FI] Token introspection (as well as other aspects related to token management) should be reviewed in depth, currently we don't solve many of the problems we see in the OAuth world.
I don't believe calls from an RS to an AS should be avoided though, on the contrary there might be an alternative to your proposal where the RS could use a public AS endpoint for the revocation list.

[Denis]  In the single sentence above, I am not proposing a scenario "where the RS could use a public AS endpoint for the revocation list". My belief is that revocation should not be handled at all,
by using "short" validity periods for access tokens. By "short", I mean a duration of about 12 hours.


15. Section 2 deals with the parameters when making calls from a RC to an AS. This section would need to be revisited.
      Hereafter are only some (of many) concerns about the current text. The most important is to identify which parameters shall be used
      and may be used when making a call to get an access token.

     The text states: "resources  Describes the rights that the RC is requesting for one or more access tokens to be used at RS’s.
     Section 2.1". Then after: "Each object contains a "type" property that determines the type of API that the RC is calling.
      (...)  The value of this field is under the control of the AS.

[FI] please provide your input to the terminology work.

 [Denis] Would you be able to post to the list where we are now, or a link where we can have an overview of the current proposed definitions ?


     The value of this field should not be under the control of the AS but of the RS.

[FI] ultimately, the field needs to correspond to what the RS provides, even if the AS is the one that generates the access token. 
Your proposal is interesting but that would put more effort on the RS side, with impacts on deployability. 


     The text states: "actions  The types of actions the RC will take at the RS". This is needed when capabilities are being used but not needed
     for the other cases. Revealing actions to an AS is against the user's privacy.

[FI] technically this could be any alias defined by the RS. Remember we discussed RS hiding strategies (ex: concealed identifier) which solve that issue.

 [Denis] A key difference between an ACL scheme and a capability scheme is the following:

  •  for an ACL scheme, the AS does not need to have any prior relationship with the RS (which is an advantage from a privacy point of view).
  •  for a capability scheme, the capabilities needs to be defined by the RO of each RS, either prior to the time of the access token request
     or at latest at the time of the access token request (which creates a delay).

     The text states: "locations  The location of the RS as an array of strings. These strings are typically URIs identifying the location of the RS." 


     It is typically URLs (not URIs) but it may also be service names so that an access token can be delegated by a first RS to a second RS
     belonging to the same service without the need for the first RS to request another access token.

[FI] delegation from a RS to another is a topic in itself, yet to be explored. I remember you sent various inputs on that, we might need to review them in detail.

[Denis] Using services names instead of URLs is not necessarily related to "delegation from a RS to another". If a RC can get such an access token, it may decide
to send it to any RS belonging to that service at any point of time. So this is relevant for the simple case without considering "delegation from a RS to another RS".

Denis



--------------4E58D5C8B715BC766CEED16C-- From nobody Tue Dec 8 01:14:24 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE1C3A045E; Tue, 8 Dec 2020 01:14:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: txauth@ietf.org, gnap-chairs@ietf.org, yaronf.ietf@gmail.com, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160741886221.14924.7896303898027203784@ietfa.amsl.com> Date: Tue, 08 Dec 2020 01:14:22 -0800 Archived-At: Subject: [GNAP] gnap - New Meeting Session Request for IETF 110 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: Tue, 08 Dec 2020 09:14:23 -0000 A new meeting session request has just been submitted by Yaron Sheffer, a Chair of the gnap working group. --------------------------------------------------------- Working Group Name: Grant Negotiation and Authorization Protocol Area Name: Security Area Session Requester: Yaron Sheffer Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mls rats sacm secdispatch secevent suit teep tls tokbind trans httpbis quic saag uta cfrg Technology Overlap: oauth People who must be present: Yaron Sheffer Roman Danyliw Leif Johansson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Dec 8 01:24:21 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6030B3A067A for ; Tue, 8 Dec 2020 01:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=sunet.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAlFwMA8O84c for ; Tue, 8 Dec 2020 01:24:17 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 BE6B93A0657 for ; Tue, 8 Dec 2020 01:24:15 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id l11so22118882lfg.0 for ; Tue, 08 Dec 2020 01:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=to:from:autocrypt:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=Pn7od8eSchHnLgKRp4dDHdxb8qBC3GFaBFN9QmKl86A=; b=DTe+QGdv7jNZ1orjI1L2MY0OSAtpceORd8LDlCP0wnKSGyxxbRcyvqed02Sro3xjuk AR2wj4azrWu22udzC4/87tLv6pXWXVmucV65pYFJ6m5lJdr3tYRMoABF6+rdpMcop6MO 75L9qm5yw8SHTiumNvtcOoQT3A1xQ0HhMKUzFpz6hsO1j4hPqj+1bJhlC99nV/SYRbGT WOKjL2OYlerxxr16Q+Uy/wnhShHRiWOFSXEv3wYmiyp3zn2AM9R8h2eto0hgg5xQplN+ 0Ei26RlbovzHgToRM41FEvwoKtjvA1nkDsw9IDLN9qkaxUorSZUjg47Y47tMu5MgCg6J c73Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:autocrypt:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=Pn7od8eSchHnLgKRp4dDHdxb8qBC3GFaBFN9QmKl86A=; b=BI3SV6GORHZW6P5ZWLUZOqp1sx+FRlakxJUgMwo/18ce4UQEwBQX+H3GvCYQBqZpML 1sZLz3zBIrD54zFVXQiVec0WScScmdXHv/jHRJwRKE4ssOV0XIYAAQXgFMLV8iEILLrr mDDaSoib/+xjmUoqqpJtJ+I3FjF+0S24acfuJSeW6x89MHcHyP6TOS/tg2aljHAuncjo IDOrbkFVLGmZsKMjP7iTuoPjUB5AnYdReAIAi116gJu6mt5zExOMQHYEtZsj4IJpBMGL X/xMzpmKw7QrpB5gwIZGO9KyboiXTC23MMvkmIaE8VaeV3vHdzMpaV76vEN+aaCCJLee 2UKA== X-Gm-Message-State: AOAM5338Wy7+cxfYUmeEoWWwL7GTj7hvqkIAvasLvGlVwWzfF4FHBoFP 5gsHgSmAEJrWImowI9ZszmaISYTPblWyMGyyGYY= X-Google-Smtp-Source: ABdhPJz+cc/npw7eiIxoONe2nSZfyBf490GDRNWcEgw09ioXD5PXJk9jmjXNL8YXd4xRxk+gkDTkLQ== X-Received: by 2002:a19:7415:: with SMTP id v21mr3478608lfe.343.1607419452963; Tue, 08 Dec 2020 01:24:12 -0800 (PST) Received: from ?IPv6:2001:6b0:7:1:a9a4:44c5:1841:69c4? ([2001:6b0:7:1:a9a4:44c5:1841:69c4]) by smtp.gmail.com with ESMTPSA id u25sm3346989lji.6.2020.12.08.01.24.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 01:24:12 -0800 (PST) To: txauth@ietf.org From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= mQENBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAG0H0xlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT6JAT4EEwEIACgCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJbtiDqBQkPDsTFAAoJENc61kMK1HjWF/8H/3JZj9Ruv9FI yrntpyCGRDv889XG+cYsUDbl7nZAYbcLUJKq9BfaMzwivPx7M0grYD84squTG/jybh2ONlxb tEANU84JWFCmWWiGnD98JvZmOWqueaOYavef2frN28zLaGh5hPBZnK3PGGCX69hPkoHD76ox NX124d8aZvPpDHuzqGibaJ3/yHPmcC7yTJ/ZKTshQe5LhHI+ev92SMSQFaJIfVq6BcHK6kNT 7tG9U8WCcdGmZ618r0HApAbgFksvnW/Eafxv0vcwZlwr32K0U2VV6fA6rFpdXjlQpV3BldDD d/eq9iwP7EZ4Jgvv38tVI2blBPfAzULVMIy1d8Y2WVm5AQ0EUkr2ogEIAL6TW0U54NLiAzES BGR+JUscV6bAlZCIZkdiG0OCOHrDqYHwbdZn7+APYIynkOAcVELWxbaIyPeA7Ot/LHN30CZZ uFdhx5HoQWRNzo5Wxohv54cf9mjcMrIHUOr0IDl+OOcRDO2L4opJlhbMHQWS3uqt85LpgzXM yMRTFRTCyXWqKvHkO4HJYsNftQtTsf/GY9WEdRVk7xcRoVXab4gLHxjoH3wox4nRDPxvzCna Du9YSTBLZHoiMXSQytHGfFS/ADoRSJm4WmGG5j+VYIm6wuXWiWA4T4EowRRK0lYSLSz6l3wU vW84t40pshQWujT6hmv1vIAGmQ82MzEpXfq6PV0AEQEAAYkBJQQYAQgADwIbDAUCW7YfnAUJ Dw7DdwAKCRDXOtZDCtR41tJUCACZFLpfHO2JT2lzNTASU6eiWacAhShxJd1+WVkAHEtfUyRn hifSMRskoyk84Ay7txCziCeL8Cmucxp7be1qommvBYITqVNw4SF080pIWF0vh4T5QJ31n1L/ w8IzQaSMMX0UBZysgGbJKIeZl8DApseTf4CEOZjY/M36Y7OBTu3znn461ygjTY8MRckZMJT0 xyVi0w0CWuYyZsxQCktIigWW5jfmeUFUMUPdsO4Jvn01uz1oEn1u73nobThdRxi32xOyeQ+m nNfzaPIJzo56D0d7wXV6nsASixx+VQq7Cf1gX+xuWqrbsY7h38FA+1o3DSIbPUfULVBYoRLi 2ThtlFYU Message-ID: <590037a8-a80c-b414-dfeb-7c253521206f@sunet.se> Date: Tue, 8 Dec 2020 10:24:10 +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: 8bit Archived-At: Subject: [GNAP] interrim #1 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, 08 Dec 2020 09:24:19 -0000 Hey folks, We are proposing a first interrim for GNAP on the 12th of January 2021 at 18:00 CET - this (we hope) corresponds to 9AM PST and noon (12:00) EST which we hope works for most of the active contributors. The goal is to close issues that can benefit from "facetime" - we propose to start with the nomenclature issue(s) but we welcome suggestions for what to do next. We are going to be using collaborative notes in codimd (and/or github issues) and either mine or yarons zoom accounts. Cheers Leif & Yaron From nobody Tue Dec 8 03:15:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9BB3A0B87 for ; Tue, 8 Dec 2020 03:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knOrwuPKovUx for ; Tue, 8 Dec 2020 03:15:03 -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 887463A0B75 for ; Tue, 8 Dec 2020 03:15:03 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id 81so16484468ioc.13 for ; Tue, 08 Dec 2020 03:15:03 -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=JMY753qsBifCX4WcUwMMzYpBT6nAFFlIzAxEHdz4Dx0=; b=RtMv0Nfkqw6iYDleZoB6QD2wNm87MQn1FIcbtJsxRkrPsimzJVgUWW+4OkuKDcNIXV 5RP/1GYmRx6PtwhxstFxw+5o+GkoUpa3MsI6BkY8FOP/m8Ydb5xIO2U8M4ZUFuFpj8py qfw9gqhPBFUqZ+uLmz/Pj+BL0Tr3GhWHyfaAiTpJaueOWWNWuHHxMrHQZmnNAYr8xfov QrzWGD/fmX8msFW+1ux/Astiy5JEUhc/4a4VyQKkF+l2KL2arxAQnXb2SNsnU8NgeMRr xLP/QEcGedY7WJmKdeFCMs3FRgZYBISJ3h4Eg+pmeqTcZdV+lqVnq73UwALQWJSUpxPU jRUw== 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=JMY753qsBifCX4WcUwMMzYpBT6nAFFlIzAxEHdz4Dx0=; b=oKuDwjsg2Wyp/K5en3I/e2VI4Qxbfym3M20+qvQuwFyKQAPNxLUWmG91/wN20SiFKC 8ftvtz5mw7dw3yApT4U3B8rOI6gvg/BWmlO8fy7dG/5CjIke5MQiBxiOyU/b9NkE5PkG DphmmTm4FNHIFZqSVK4jzxETsRMYXA+4D2E+2i2/53I1Xrd5SdI98hqJR3733yMvSctq 8Xe6Eg9VVu/p0Kc+VBeZgzN/HdrObTWQcXAx5LOySV4RlDNmwpqqmXVi2zbnqdGrQtVC gzJme9Cfh/F+zF3jnPNrrgDW1xkNM+mMnztu8NO6PYQwJx7iVUxkwspRsRDMboeZR+rg c5ow== X-Gm-Message-State: AOAM533SGeVP/+NYIQAqS78sOCMii7836jt7+3s8m3UMuB2DuvH7QvHm t8ylduREGb/FWSKGYnLogNsAS8omyWFQhGXjz2A= X-Google-Smtp-Source: ABdhPJxxuvdepgOJ3ychHjp9HWYFAhtAkTBc0Gd/EOpKh0sfIHAqLo0V9snddfxrXbxR4P1yuKEOf9yl4b1AvfKLzVQ= X-Received: by 2002:a5e:a815:: with SMTP id c21mr23377004ioa.141.1607426102703; Tue, 08 Dec 2020 03:15:02 -0800 (PST) MIME-Version: 1.0 References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> In-Reply-To: <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> From: Fabien Imbault Date: Tue, 8 Dec 2020 12:14:51 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000dabf4605b5f20d3d" Archived-At: Subject: Re: [GNAP] Quick review of draft-ietf-gnap-core-protocol-00 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 11:15:09 -0000 --000000000000dabf4605b5f20d3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, Thanks for your interesting email. It would be interesting to get feedback from others in the group, as it is a fairly different model (but which makes sense). My comments in red marked with [FI2]. My main concern is that a big part can't be made mandatory as a default behavior, because it assumes too much on the RS side. But I get the feeling that it could come as an optional pre-negociation. I'll think about it more. Best Fabien On Mon, Dec 7, 2020 at 5:11 PM Denis wrote: > Hi Fabien, > > I have been quite long before responding to your email. The response took > me occupied for a long while too. > > Hi Denis, > > I've been thinking more about your feedback. Marked with [FI] in your > initial comments. > > We probably need to address your feedback early on, and make sure the WG > is fine with those. > Overall I believe we can achieve much of what you'd want regarding > privacy, without impacting too much the architecture. > > [Denis] I hope so (and cross my fingers). > > Fabien > > On Wed, Oct 21, 2020 at 7:20 PM Fabien Imbault > wrote: > >> Hi Denis, >> >> The "many options" is only a temporary state, the goal was to expose the >> decisions that need to be made to the mailing list. We can quickly reduc= e >> to a manageable level by having focused discussions. >> >> As for the remainder of your comments, the only item we considered so fa= r >> was one of principle: that privacy is an important goal of the work. The >> rest of the focus was on taking the best out of XYZ and XAuth. So >> incorporating the discussions that occurred just before the focus group >> wasn't a goal. You can already see that with regards to terminology, whe= re >> insightful discussions occurred but the paint was really very fresh. >> >> I find what you explain really interesting. It will need to be analyzed >> in detail. The caveat is that we have less background experience of what= it >> means in practice (compared to the current document vs OAuth2). >> I guess it will require a bit of experimentation, to avoid corner cases. >> >> More specific comments/questions coming later :-) >> >> Fabien >> >> >> Le mer. 21 oct. 2020 =C3=A0 17:58, Denis a =C3=A9cr= it : >> >>> Hi, >>> >>> I haven't read all the document in details, but I have browsed through >>> it: this took me about 3 hours. >>> As it is, I don't consider that the current text (more than 100 pages != ) >>> is a "good starting point". >>> >>> The less that I can say is that the document is far from being crystal >>> clear, is too complex and includes so many options >>> (without indicating which parameters are required and which ones are >>> optional) that it will be impossible to claim that >>> an implementation complies with it. >>> >>> In addition, it is unfortunate that many of the discussions we have had >>> on the mailing list have not been incorporated by the design team. >>> >>> Here are some comments: >>> >>> 1. An overview is missing since the various features are only being >>> discovered while reading the document. >>> >>> 2. A key question that might interest a reader is the following: what >>> are the common points and the main differences with OAuth ? >>> >>> 3. The whole document is "AS centric" while it should also be "RS >>> centric". These two concepts have been explained on the mailing list. >>> >> [FI] indeed it is centered around the AS. What's your proposition if we > were to change the text? > Notice that most business scenarios today require an AS centric approach. > We've seen from previous discussion that it doesn't preclude from enablin= g > more privacy. > > [Denis] As you write "business scenarios today require an AS centric > approach" as long as a single company supporting one AS and several RSs i= s > involved. > On the Internet, some servers are already proposing the intermediation of > a several identity providers. This should be generalized. > > You raised a good question: What's your proposition if we were to change > the text? > > Page 9. The current text is: > > * (1) The RC attempts to call the RS (Section 10.4) to determine what > access is needed. The RS informs the RC that access can be granted throu= gh > the AS. > Note that for most situations, the RC already knows which AS to > talk to and which kinds of access it needs. > * (2) The RC requests access at the AS (Section 2). > * (3) The AS processes the request and determines what is needed to > fulfill the request. The AS sends its response to the RC (Section 3). > > Section 10.4 is the last section just before the acknowledgement section > and refers to a "GNAP endpoint" while this term is not used before. > I guess that this reference is incorrect. > > While I don't intend to cover all possible scenarios, I would detail the > first steps differently: > > * (1) If the RC has never called the RS before, the RC calls the R= S > to determine which ASs are trusted by that RS > and which claim types are requested for the operation he > wishes to perform. If the RC knows the language preference(s) > of the end-user they are indicated in this call. > [FI2] I guess that is easy to do (even for an AS centric scenario), yet can we assume the RS will be able to provide that functionality? Looks like a kind of optional pre-flow ? (since a part of the flow stays the same) : client -> AS -> token -> RS * (2) The RS responds by indicating one or more ASs and for each AS which claim types are requested. The RS also indicates, in a "display" field, for each attribute type the reason(s) for requesting it. This information is intended to be displayed to the end-user by the RC, if the end-user is interested to know it. [FI2] same as before > * (3) The end-user may choose to see the "display" field from the > previous message in his favourite language and then chooses which AS(s) t= o > call > and gives his consent to call these ASs (or a subset of > them) together for the set of a claim types requested (or a subset of > theses claim types). > The RC memorises the *user consent* and the choices made > by the user for that RS and for the requested operation. > > Note: the end-user MUST be able to know which kind of > end-user identifier claim is requested by an AS, in particular whether it > is globally unique, > unique to the AS only, unique to the RS only o= r > ephemeral (valid for that RS during a session with the AS). This has > implications with respect to privacy. > [FI2] this is similar to what is currently the display field managed by the AS. Here you propose a big change in spirit : the client is responsible for managing user consent, but that seems a potentially viable option. > * (4) The RC authenticates to the AS(s). > [FI2] ok (the case of multiple ASs probably needs some fine tuning) > * (5) The RC requests one or more access tokens to each selected A= S > that should contain the selected set of claim types. > The target RS may be either a URL in clear text or may be > a set of bits that is not meaningful to the AS and that will not be > generated twice by the same RC. > The later case allows to hide the identity of the RS to > the AS, but still allows the RC to target the access token to the > appropriate RS URL. The later case > prevents the AS to act as Big Brother. > [FI2] Aligned with what we worked on a few months ago, and that I planned to propose as a new issue as part of the privacy effort > * (6) Each AS sends back one or more access tokens to the RC. > [FI2] ok > * (7) The RC verifies that the claim types inserted within each > access token correspond to the claim types that have been requested. > If not, the access token may be discarded. Note: In order > to be able to perform that verification, access tokens are not opaque to > the RC. > If such a verification cannot be done, the RC may discard > the access token. > [FI2] Currently in the terminology, we assume an access token is opaque. Because it makes interop and changes easier to implement (at the cost of not knowing what they do, which is a potential trust issue). Wouldn't be opposed to the idea of non-opaque tokens in principle, yet this makes it mandatory to define formats, or at least allow a registry of accepted formats (JWT etc.). Very often the existing formats are pretty loose (the fields aren't well defined in many cases), so there would be some significant work to make sure there's sufficient compatibility. Wondering if that would fall into the charter's scope. * (8) The RC sends the access token(s) to the RS together with the > operation its wishes to perform. > [FI2] ok > * (9) The RS determines if the access token(s) is (are) adequate > for the operation by examining the access token(s). > [FI2] ok > * (10) If the access token(s) is (are) accepted, the RS provides a > response to the RC for the requested operation. > [FI2] ok > The process may be optimized with the following step: > > * (0) The RC performs a look up in the table of previous operations > performed by the user and : > > - if it finds the same operation for the same user fo= r > that RS associated with still valid access tokens, it goes to step (8). > - if it finds the same operation for the same user fo= r > that RS associated with a no more valid access token, it fetches an updat= ed > access token and goes to step (7). > - otherwise, it goes to step (1). > > One important explanation: RFC 6973 (Privacy Considerations for Internet > Protocols) mentions: > > 7.2. User Participation > > a. User control. What controls or consent mechanisms does the > protocol define or require before personal data or identifiers are shared > or exposed via the protocol ? > > (...) > > 7.2. User Participation > > d. Preference expression. Does the protocol provide ways for initiators > to express individuals=E2=80=99 preferences to recipients or intermediari= es with > regard to the collection, use, > or disclosure of their > personal data? > > Steps (2) and step (3) are the responses to these two questions. > [FI2] makes sense > 4. The document only speaks about "*the* AS", as if only one AS would >>> exist which is obviously not the case. >>> The first access made to a RS shall be able to identify which ASs >>> are trusted by the RS. In addition, for each trusted AS, the RS should = be >>> able >>> to indicate which access rights are needed to perform every >>> operation possible at that stage. For any subsequent stage, the RS may = also >>> indicate >>> which attributes or access rights are needed to perform each >>> subsequent operation. >>> >> [FI] There's also two related questions : a) do we allow multiple-AS > scenarios? b) do we allow other AS deployment options, and if so, how? > (like a personal AS on your phone). > > [Denis] My answer is option a). The previous response illustrates how to > handle that case. I consider that an AS is a server (the "S" from "AS" > tells it) and as such it cannot be on a phone. > [FI2] here Francis and Tom seem to have different opinions. In practice however, I don't see how to make it work well (meaning securely) on a phone without a significant redesign at lower level interfaces than HTTP (as discussed in another thread). So your remark doesn't seem to be a problem at that stage. > 5. "API=E2=80=99s documentation" versus "API discovery". Whereas the API= =E2=80=99s >>> documentation is static and not necessarily up to date or the RC softwa= re >>> is not necessarily up to date, API discovery provides real time >>> information which is necessarily up to date. >>> >>> There should be an API discovery mechanism for RSs. >>> >> [FI] is that our job to do that? There are already existing discovery > mechanisms in the wild that people could use. > > [Denis] The current document includes a section 9 called "Discovery" (pag= e > 92). This section describes discovery functions for an AS only. > In the same way, discovery functions for a RS could be described. In > particular, whether an initial authentication to the RS is needed or not > and, if not, which operations can be requested, which ASs are trusted by > that RS and which claim types are requested for these operations. > [FI2] Well, the spec concerns AS implementers a lot, so we can expect the requirements to be implemented. But the RS side is way more complex, it will be hard to ask every API vendor to change its implementation. In any case, this means we can't assume much on the RS side, so at most it would be optional if we were doing this. > >>> Using an appropriate HTTP OPTIONS request, the RC should be able to >>> query the RS in order to know *at any point of time*: >>> >>> >>> - the operations that can be done (i.e. which methods are available >>> on which data objects), and >>> - the access control characteristics associated with each of these >>> operations (i.e. which ASs are being trusted by the RS >>> and what should be the incorporated into access token(s) in terms of >>> attributes types (and optionally attribute values) >>> or in terms of capabilities (i.e. permissions granted). >>> >>> 6. The "user consent" phase has been ignored. It should be done at the >>> RS. Using information obtained from a RS, a RC should be able >>> to select which AS it wants to contact and explicitly agree to >>> request the mentioned attributes to that AS. Alternatively, when the us= er >>> consent phase >>> is not done at the RS, it shall be done at the AS. >>> >> [FI] To be discussed further. I believe an optional separate Interaction > Server solves this case, without disruption for standard use cases (OAuth= 2 > like) that are likely to remain. > > [Denis] See the scenario with the 10 steps above. I believe that there is > no need for an optional separate Interaction Server. > [FI2] there is if we don't want to impose the 10 steps above and still provide some level of privacy (especially step 5). As I explained, I don't think we can impose it in practice. > >>> 7. The content and the format of access tokens shall not be considered >>> to be opaque to the RC so that the RC can inspect it. >>> This is a matter of confidence to make sure for the RC (and for the >>> user) that no "extra" information has been included by the AS into the >>> access token. >>> >> [FI] This might go a bit further than the GNAP's mandate (especially if > it becomes a mandatory requirement). But supposing we support non-opaque > tokens, > does it preclude supporting opaque tokens? It's just a different trust > model, which makes sense if people agree with your premises (previous > items), > but that are less relevant if people still consider the AS as the central > piece. Also one great thing with opaque tokens is that it makes the syste= m > easier to upgrade > (you don't really care about what a token is). > > [Denis] Privacy is not more relevant for an AS-centric model than for a > RS-centric model. In particular, a RC should be able to verify which kind > of end-user identifier claim > has been incorporated into the access token by the AS, in particular > whether it is globally unique, unique to the AS only, unique to the RS on= ly > or ephemeral (valid for > that RS during a session with the AS). > [FI2] ok, see discussion on whether tokens should be opaque or not. > I suppose that the use of structured access tokens should be recommended. > This means,in particular, that from the very beginning, we should > incorporate a version number > inside each access token. > > One alternative way would be to allow RS call to AS for verification > (including revocation status) and include a checksum. > > [Denis] The RC, i.e. not the RS, should be able to perform such > verification before presenting the access token to the RS. So this > alternative way would not work. > [FI2] then there could be a similar API for the client (cf discussion on similarities between introspection/management APIs). > > 8. "Resource Owner (RO) : Authorizes the request from the RC to the RS", >>> full stop. The RO is associated with a RS, not with an AS. >>> The RS can know in advance with attributes or access rights are >>> needed to grant a given operation. >>> >> [FI] ideally makes sense I think, but need to check the practical > implications. Related to terminology #6. > > [Denis] Fine. > > 9. The model should allow the use of both Access Control Lists and of >>> Capabilities Lists. >>> >>> >>> - Access control lists contain identifiers of users and/or >>> identifiers of users groups or identity claims in relationship with = an >>> operation. >>> - Capabilities lists contains operations granted on services within >>> a RC. >>> >>> As a consequence, access tokens may contain identifiers of users >>> and/or identity claims and/or identifiers of users groups and/or >>> capabilities. >>> Whereas identifiers of users and/or identifiers of users groups >>> and/or identity claims may be managed by an AS independently from RSs, >>> this is not the case for capabilities where a RO associated with a >>> RS needs to interact with the AS either in advance or in real time >>> (which makes such mechanism much more complex). >>> >> > [FI] We had several discussions on this topic, and I still consider the > current approach to be the right path. I don't think your scenario is > really more complex, > that's basically what people are doing when using a policy engine (which > can be as simple as casbin.org for instance) to generate access tokens. > More fundamentally, ensuring least privilege using ACLs is known to be a > hard problem. > > [Denis]. I am wondering what you mean when you write "I still consider th= e > current approach to be the right path". I do prefer ACLs, but capabilitie= s > is another possibility. > I would have no problem if we say that capabilities are not supported by > the model. :-) > [FI2] likewise, I have no problem to say that ACLs are not supported ;-) In practice also, if we generalize token binding, capabilities are less of an issue. > 10. In the case where access control lists are being used, there should > be a possibility for a RC, for privacy reasons, to hide the identifier > > of the RS to the AS (usually a URL) when requesting an access token. >>> A method able to support such feature has been discussed extensively on= the >>> mailing list. >>> >> [FI] depends on decision regarding previous item. > > [Denis] I don't understand why it would be related to the previous item. > An access token can be targeted to a given RS (or a given service) > irrespective whether it carries information usable for an ACL scheme or > for a Capability scheme. > [FI2] What I meant is that depending on whether we use ACLs or not ("In the case where access control lists are being used"), the item is important or doesn't exist. > >>> 11. The text states: "Authorization Server (AS) Manages the requested >>> delegations for the RO". This is only one of two possibilities. >>> The interaction between a RO and an AS should be considered as an >>> option. If a RO needs to interact, for privacy reasons, it should >>> preferably >>> interact with the RS only. >>> >> [FI] The problem with working at the RS level is that it makes the > integration harder (we don't exactly know what people will implement). > As a consequence, I would be in favor of an optional separation of that > issue in an Interact Server, which could be distinct from the AS to > alleviate privacy concerns. > > [Denis] My point was/is about the quoted sentence: "Authorization Server > (AS) Manages the requested delegations for the RO" which is incorrect in > the general case. > Furthermore, interactions with a RO create delays in the protocol, so I a= m > favouring situations where a RO does not need to interact at all, in orde= r > to obtain a better throughput. > Anyway, I am not in favour of introducing a new entity like "an Interact > Server". > [FI2] the IS is possibly just a part of the AS that deals with front-end requirements. And in case people would like to implement privacy requirements without the 10 step process described above where the RS needs to be compatible, separating the AS and the IS seems like a viable option. I see no other way that doesn't add additional dependencies that we don't control. > >>> 12. The text states: "Resource A protected API served by the RS and >>> accessed by the RC. Access to this resource is delegated by the RO as p= art >>> of the grant process". >>> The second part of the sentence should be deleted since a RO is >>> not necessarily involved in the grant process. >>> >> [FI] Yes, more generally we should check that we can deal with user =3D > RO (usually considered as the default case) and user !=3D RO (not often > carefully designed). > I think the text already goes into much more details than OAuth2 for this > (cf sequences 1.4). > > [Denis] My preference is to use the term "end-user" for the entity > interacting locally with the RC. > [FI2] same for me > > >>> 13. The text states: "Resource Client (RC, aka "client") Requests >>> tokens from the AS and uses tokens at the RS. >>> An instance of the RC software is identified by its key, which ca= n >>> be known to the AS prior to the first request". >>> >>> This is confusing. The key does not necessarily identify an >>> instance of the RC software. >>> An instance of the RC software uses a binding key which (for >>> privacy reasons) should be dynamic but which may alternatively be >>> static. >>> >> [FI] The client instance solves those issues. Might need to update the > way it is described in the text. > > [Denis] Let us have a look at the text in a subsequent version. > [FI2] there's PR132 on that > > 14. For privacy reasons, calls from an RS to an AS, such as token >>> introspection, should be avoided. >>> >> [FI] Token introspection (as well as other aspects related to token > management) should be reviewed in depth, currently we don't solve many of > the problems we see in the OAuth world. > I don't believe calls from an RS to an AS should be avoided though, on th= e > contrary there might be an alternative to your proposal where the RS coul= d > use a public AS endpoint for the revocation list. > > [Denis] In the single sentence above, I am not proposing a scenario > "where the RS could use a public AS endpoint for the revocation list". My > belief is that revocation should not be handled at all, > by using "short" validity periods for access tokens. By "short", I mean a > duration of about 12 hours. > [FI2] well, that's one way of doing it, it would simplify some things. But the problem (and a big one) is that if you have no revocation mechanism, there's no way to implement sessions, and that's what many people are actually trying to do. > >>> 15. Section 2 deals with the parameters when making calls from a RC to >>> an AS. This section would need to be revisited. >>> Hereafter are only some (of many) concerns about the current text= . >>> The most important is to identify which parameters shall be used >>> and may be used when making a call to get an access token. >>> >>> The text states: "resources Describes the rights that the RC is >>> requesting for one or more access tokens to be used at RS=E2=80=99s. >>> Section 2.1". Then after: "Each object contains a "type" property >>> that determines the type of API that the RC is calling. >>> (...) The value of this field is under the control of the AS. >>> >> [FI] please provide your input to the terminology work. > > [Denis] Would you be able to post to the list where we are now, or a lin= k > where we can have an overview of the current proposed definitions ? > [FI2] yes of course. See : - the process related to terminology https://mailarchive.ietf.org/arch/msg/txauth/XfeobMcrycw4TEAIOUkX0El1EWo/ - yesterday's email https://mailarchive.ietf.org/arch/msg/txauth/fA0KjzAriINGIIzjLmR3OAHiOqs/ (my proposal, from our discussion above there are some differences, and that will be interesting to discuss) > > The value of this field should not be under the control of the AS bu= t >>> of the RS. >>> >> [FI] ultimately, the field needs to correspond to what the RS provides, > even if the AS is the one that generates the access token. > Your proposal is interesting but that would put more effort on the RS > side, with impacts on deployability. > >> >>> The text states: "actions The types of actions the RC will take >>> at the RS". This is needed when capabilities are being used but not nee= ded >>> for the other cases. Revealing actions to an AS is against the >>> user's privacy. >>> >> [FI] technically this could be any alias defined by the RS. Remember we > discussed RS hiding strategies (ex: concealed identifier) which solve tha= t > issue. > > [Denis] A key difference between an ACL scheme and a capability scheme i= s > the following: > > - for an ACL scheme, the AS does not need to have any prior > relationship with the RS (which is an advantage from a privacy point o= f > view). > - for a capability scheme, the capabilities needs to be defined by > the RO of each RS, either prior to the time of the access token reques= t > or at latest at the time of the access token request (which creates a > delay). > > > The text states: "locations The location of the RS as an array of >>> strings. These strings are typically URIs identifying the location of t= he >>> RS." >>> >> >>> It is typically URLs (not URIs) but it may also be *service names* >>> so that an access token can be delegated by a first RS to a second RS >>> belonging to the same service without the need for the first RS to >>> request another access token. >>> >> [FI] delegation from a RS to another is a topic in itself, yet to be > explored. I remember you sent various inputs on that, we might need to > review them in detail. > > [Denis] Using services names instead of URLs is not necessarily related t= o > "delegation from a RS to another". If a RC can get such an access token, = it > may decide > to send it to any RS belonging to that service at any point of time. So > this is relevant for the simple case without considering "delegation from= a > RS to another RS". > > Denis > > >>> Denis >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > --000000000000dabf4605b5f20d3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

Thanks= for your interesting email. It would be interesting to get feedback from o= thers in the group, as it is a fairly=C2=A0different model (but which makes= sense).

My comments in red marked with [FI2]. My = main concern is that a big part can't be made mandatory as a default be= havior, because it assumes too much on the RS side. But I get the feeling t= hat it could come as an optional pre-negociation. I'll think about it m= ore.

Best
Fabien

On Mon, Dec 7, 202= 0 at 5:11 PM Denis <denis.ietf@fre= e.fr> wrote:
=20 =20 =20
Hi Fabien,

I have been quite long before responding to your email. The response took me occupied for a long while too.

=20
Hi Denis,=C2=A0

I've been thinking more about=C2=A0your=C2=A0feedback. M= arked with [FI] in your initial comments.

We probably need to address your feedback early on, and make sure the WG is fine with those.
Overall I believe we can achieve much of what you'd want regarding privacy, without impacting too much the architecture.

[Denis] I hope so (and cross my fingers).


Fabien=C2=A0

On Wed, Oct 21, 2020 at 7:2= 0 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Denis,

The "many options" is only a te= mporary state, the goal was to expose the decisions that need to be made to the mailing list. We can quickly reduce to a manageable level by having focused discussions.

As for the remainder of your comments, the only item we considered so far was one of principle: that privacy is an important goal of the work. The rest of the focus was on taking the best out of XYZ and XAuth. So incorporating the discussions that occurred just before the focus group wasn't a goal. You can already see that with regards to terminology, where insightful discussions occurred but the paint was really very fresh.=C2=A0

I find what you explain really interesting. It will need to be analyzed in detail. The caveat is that we have less background experience of what it means in practice (compared to the current document vs OAuth2).
I guess it will require a bit of experimentation, to avoid corner cases.

More specific comments/questions coming later :-)=C2=A0

Fabien=C2=A0


Le mer. 21 oct. 2020 = =C3=A0 17:58, Denis <denis.ietf@free.fr> a =C3=A9crit=C2=A0:

Hi,

I haven't read all the document in details, but I have browsed through it: this took me about 3 hours.
As it is, I don't consider that the current tex= t (more than 100 pages !) is a "good starting point".

The less that I can say is that the document is far from being crystal clear, is too complex and includes so many options
(without indicating which parameters are required and which ones are optional) that it will be impossible to claim that
an implementation complies with it.

In addition, it is unfortunate that many of the discussions we have had on the mailing list have not been incorporated by the design team.

Here are some comments:

1. An overview is missing since the various features are only being discovered while reading the document.

2. A key question that might interest a reader is the following: what are the common points and the main differences with OAuth ?

3. The whole document is "AS centric" while it s= hould also be "RS centric". These two concepts = have been explained on the mailing list.

[FI] indeed it is centered around the AS. What's your proposition if we were to change the text?
Notice that most business scenarios today require an AS centric approach. We've seen from previous discussion that it doesn't preclude from enablin= g more privacy.

[Denis] As you write "business scenarios today require an AS centric approach" as long as a single company supporting one AS and several RSs is involved.
On the Internet, some servers are already proposing the intermediation of a several identity providers. This should be generalized.

You raised a good question: What's your proposition if we were t= o change the text?

Page 9. The current text is:

=C2=A0=C2=A0 *=C2=A0 (1) The RC attempts to call the RS (Section 10.= 4) to determine what access is needed.=C2=A0 The RS informs the RC that access can be granted through the AS.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note that for most situations, t= he RC already knows which AS to talk to and which kinds of access it needs.
=C2=A0=C2=A0 *=C2=A0 (2) The RC requests access at the AS (Section 2)= .
=C2=A0=C2=A0 *=C2=A0 (3) The AS processes the request and determines = what is needed to fulfill the request.=C2=A0 The AS sends its response to the RC (Section 3).

Section 10.4 is the last section just before the acknowledgement section and refers to a "GNAP endpoint" while this term is = not used before.
I guess that this reference is incorrect.

While I don't intend to cover all possible scenarios, I would detail the first steps differently:

=C2=A0=C2=A0 *=C2=A0 (1)=C2=A0=C2=A0=C2=A0 If the RC has never calle= d the RS before, the RC calls the RS to determine which ASs are trusted by that RS
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 and which claim types are requested for the operation he wishes to perform. If the RC knows the language preference(s)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 of the end-user they are indicated in this call.

[FI2] I guess that is easy to = do (even for an AS centric scenario), yet can we assume the RS will be able= to provide that functionality?
Lo= oks like a kind of optional pre-flow ? (since a part of the flow stays the = same) : client -> AS -> token -> RS

=C2= =A0=C2=A0 *=C2=A0 (2)=C2=A0=C2=A0=C2=A0 The RS responds by indicating one o= r more ASs and for each AS which claim types are requested.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 The RS also indicates, in a "display" field= , for each attribute type the reason(s) for requesting it.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 This information is intended to be displayed to the end-user by the RC, if the end-user is interested to know it.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

[FI2] same as before=C2= =A0

=C2=A0=C2=A0 *=C2=A0 (3)=C2=A0=C2=A0=C2=A0 The end-user may choose t= o see the "display" field from the previous message in his favourite language and then chooses which AS(s) to call
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 and gives his consent to call these ASs (or a subset of them) together for the set of a claim types requested (or a subset of theses claim types).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 The RC memorises the user consent and the choices made by the user for that RS and for the requested operation.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Note: the end-user MUST be able to know which kind of end-user identifier claim is requested by an AS, in particular whether it is globally unique,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 unique to the AS only, unique to the RS only or ephemeral (valid for that RS during a session with the AS). This has implications with respect to privacy.=C2=A0

[FI2] this is similar to what is cu= rrently the display field managed by the AS.=C2=A0
Here you propose a big change in spirit : the client is re= sponsible for managing user consent, but that seems a potentially viable op= tion.=C2=A0 =C2=A0

=C2=A0=C2=A0 *=C2=A0 (4)=C2=A0=C2=A0=C2=A0 The RC authenticates to t= he AS(s).

[FI2] ok (the = case of multiple ASs probably needs some fine tuning)

=C2=A0=C2=A0 *=C2=A0 (5)=C2=A0=C2=A0=C2=A0 The RC requests one or mo= re access tokens to each selected AS that should contain the selected set of claim types.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 The target RS may be either a URL in clear text or may be a set of bits that is not meaningful to the AS and that will not be generated twice by the same RC.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 The later case allows to hide the identity of the RS to the AS, but still allows the RC to target the access token to the appropriate RS URL. The later case
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 prevents the AS to act as Big Brother.

<= /blockquote>
[FI2] Aligned with what we worked = on a few months ago, and that I planned to propose as a new issue as part o= f the privacy effort=C2=A0

=C2=A0=C2=A0 *=C2=A0 (6) =C2=A0=C2=A0 Each AS sends back one or more= access tokens to the RC.

[FI2] ok=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0 * (7)=C2=A0=C2=A0=C2=A0 The RC verifies that the = claim types inserted within each access token correspond to the claim types that have been requested.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 If not, the access token may be discarded. Note: In order to be able to perform that verification, access tokens are not opaque to the RC.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 If such a verification cannot be done, the RC may discard the access token.

[FI2]=C2=A0Currently in the terminology, we assume an access t= oken is opaque. Because it makes = interop and changes easier to implement (at the cost of not knowing what th= ey do, which is a potential trust issue).=C2=A0
Wouldn't be opposed to the idea of non-opaque tokens in p= rinciple, yet this makes it mandatory to define formats, or at least allow = a registry of accepted formats (JWT etc.). Very often the existing formats = are pretty loose (the fields aren't well defined in many cases), so the= re would be some significant work to make sure there's sufficient compa= tibility. Wondering if that would fall into the charter's scope.=C2=A0<= /font>


=C2=A0=C2=A0 *=C2=A0 (8)=C2=A0=C2=A0=C2=A0 The RC sends the access t= oken(s) to the RS together with the operation its wishes to perform.

= [FI2] ok

=C2=A0=C2=A0 *=C2=A0 (9) =C2=A0=C2=A0 The RS determines if the acces= s token(s) is (are) adequate for the operation by examining the access token(s).

[FI2] ok=C2=A0

=C2=A0=C2=A0 *=C2=A0 (10)=C2=A0 If the access token(s) is (are) acce= pted, the RS provides a response to the RC for the requested operation.

<= /blockquote>
[FI2] ok=C2=A0

The process may be optimized with the following step:

=C2=A0=C2=A0=C2=A0 * (0) =C2=A0 The RC performs a look up in the tab= le of previous operations performed by the user and :

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - if it finds the same ope= ration for the same user for that RS associated with still valid access tokens, it goes to step (8).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 - if it finds the same operation for th= e same user for that RS associated with a no more valid access token, it fetches an updated access token and goes to step (7).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - otherwise, it goes to step = (1).

One important explanation: RFC 6973 (Privacy Considerations for Internet Protocols) mentions:

7.2.=C2=A0 User Participation

=C2=A0=C2=A0 a.=C2=A0 User control.=C2=A0 What controls or consent = mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol ?=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (...)

7.2.=C2=A0 User Participation

d.=C2=A0 Preference expression.=C2=A0 Does the protocol provide wa= ys for initiators to express individuals=E2=80=99 preferences to recipient= s or intermediaries with regard to the collection, use,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or discl= osure of their personal data?

Steps (2) and step (3) are the responses to these two questions.

=
[FI2] makes sense=C2=A0

4= . The document only speaks about "the AS"= ;, as if only one AS would exist which is obviously not the case.
=C2=A0=C2=A0=C2=A0 The first access made to a RS sh= all be able to identify which ASs are trusted by the RS. In addition, for each trusted AS, the RS should be able
=C2=A0=C2=A0=C2=A0 to indicate which access rights = are needed to perform every operation possible at that stage. For any subsequent stage, the RS may also indicate
=C2=A0 =C2=A0 which attributes or access rights are= needed to perform each subsequent operation.

[FI]=C2=A0There's also two relat= ed questions : a) do we allow multiple-AS scenarios? b) do we allow other AS deployment options, and if so, how? (like a personal AS on your phone).

[Denis] My answer is option a). The previous response illustrates how to handle that case. I consider that an AS is a server (the "S" from "AS" tells it) and as such it cannot be = on a phone.

[FI2] he= re Francis and Tom seem to have different opinions. In practice however, I = don't see how to make it work well (meaning securely) on a phone withou= t a significant redesign at lower level interfaces than HTTP (as discussed = in another thread).=C2=A0
So your = remark doesn't seem to be a problem at that stage.=C2=A0

5= . "API=E2=80= =99s documentation" versus "API discovery"= ;. Whereas the API=E2=80=99s documentation is static and not necessarily up to date or the RC software
=C2=A0=C2=A0=C2=A0 is not necessarily up to date, A= PI discovery provides real time information which is necessarily up to date.

=C2=A0=C2= =A0=C2=A0 There should be an API discovery mechanism for RSs.

[FI] is that our job to do that? There are already existing discovery mechanisms in the wild that people could use.

[Denis] The current document includes a section 9 called "Discovery" (page 92). This section describes discovery fun= ctions for an AS only.
In the same way, discovery functions for a RS could be described. In particular, whether an initial authentication to the RS is needed or not
and, if not, which operations can be requested, which ASs are trusted by that RS and which claim types are requested for these operations.

[F= I2] Well, the spec concerns AS implementers a lot, so we can expect the req= uirements to be implemented. But the RS side is way more complex, it will b= e hard to ask every API vendor to change its implementation. In any case, t= his means we can't assume much on the RS side, so at most it would be o= ptional if we were doing this.=C2=A0=C2=A0


=C2=A0=C2=A0=C2=A0 Using an appropriate HTTP OPTION= S request, the RC should be able to query the RS in order to know at any point of time:

  • the operations that can be done (i.e. which methods are available on which data objects), and
  • the access control characteristics associated with each of these operations (i.e. which ASs are being trusted by the RS
    and what should be the incorporated into access token(s) in terms of attributes types (and optionally attribute values)
    or in terms of capabilities (i.e. permissions granted).

6= . The "user consent" phase has been ignored. It= should be done at the RS. Using information obtained from a RS, a RC should be able
=C2=A0 =C2=A0 to select which AS it wants to contac= t and explicitly agree to request the mentioned attributes to that AS. Alternatively, when the user consent phase
=C2=A0 =C2=A0 is not done at the RS, it shall be do= ne at the AS.

[FI] To be discussed further. I believe an optional separate Interaction Server solves this case, without disruption for standard use cases (OAuth2 like) that are likely to remain.

[Denis] See the scenario with the 10 steps above. I believe that there is no need for an optional separate Interaction Server.

[FI2] there is if we don&#= 39;t want to impose the 10 steps above and still provide some level of priv= acy (especially step 5).=C2=A0=C2=A0
As I explained, I don't think we can impose it in practice.=C2=A0


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
=C2=A0=C2=A0=C2=A0 This is a matter of confidence t= o make sure for the RC (and for the user) that no "extra&q= uot; information has been included by the AS into the access token.

[FI] This might go a bit further than the GNAP's=C2=A0mandate (especially if it becomes a mandatory requirement). But supposing we support non-opaque tokens,
does it preclude supporting opaque tokens? It's just a different trust model, which makes sense if people agree with your premises (previous items),
but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade
(you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for
that RS during a session with the AS).

[FI2] ok, see discussion on whether tokens should be o= paque or not.

I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number
inside each access token.


One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum.

[Denis]=C2=A0 The RC, i.e. not the RS, should be able to perform suc= h verification before presenting the access token to the RS. So this alternative way would not work.

[FI2] then there could be a similar API for the client (cf di= scussion on similarities between introspection/management APIs).

8= . "Resource Owner (RO) : Authorizes the request from the RC to the RS", full stop. The RO is associated with a RS, not with an AS.
=C2=A0=C2=A0=C2=A0 The RS can know in advance with = attributes or access rights are needed to grant a given operation.

[FI] ideally makes sense I think,=C2=A0but need to check the=C2=A0practical implications= . Related to terminology #6.=C2=A0

[Denis] Fine.


9= . The model should allow the use of both Access Control Lists and of Capabilities Lists.

  • Access control lists contain identifiers of users and/or identifiers of users groups or identity claims in relationship with an operation.
  • Capabilities lists contains operations granted on services within a RC.

=C2=A0=C2=A0=C2=A0=C2=A0 As a consequence, access tokens may contain identifiers of users and/or identity claims and/or identifiers of users groups and/or capabilities.
=C2=A0=C2=A0=C2=A0 Whereas identifiers of users and= /or identifiers of users groups and/or identity claims may be managed by an AS independently from RSs,
=C2=A0=C2=A0=C2=A0 this is not the case for capabil= ities where a RO associated with a RS needs to interact with the AS either in advance or in real time
=C2=A0=C2=A0=C2=A0 (which makes such mechanism much= more complex).


[FI] We had several discussions on this topic,=C2=A0and I still consider the current approach to be the right path. I don't think your scenario is really more complex,
that's basically what people are doing when using a polic= y engine (which can be as simple as casbin.org for instance) to generate access tokens.=C2=A0
More fundamentally, ensuring least privilege using ACLs is known to be a hard problem.

[Denis]. I am wondering what you mean when you write "I still consider the current approach to be the right path". I do prefer ACLs, but capabilities is another possibility.
I would have no problem if we say that capabilities are not supported by the model. :-)

[FI2] likewise, I have no problem to say that ACLs are not su= pported ;-) In practice also, if we generalize token binding, capabilities = are less of an issue.
=C2=A0

10. In the case where access control lists are being used, there should be a possibility for a RC, for privacy reasons, to hide the identifier

=C2=A0=C2=A0=C2=A0=C2=A0 of the RS to the AS (usually a URL) when requesting an access token. A method able to support such feature has been discussed extensively on the mailing list.

[FI] depends on decision regarding previous item.=C2=A0

[Denis] I don't understand why it would be related to the previous item. An access token can be targeted to a given RS (or a given service)
irrespective whether it carries information usable for an ACL scheme or for a Capability scheme.

[FI2]=C2=A0 What I meant is that depending on whether= we use ACLs or not ("In the case where access control lists are being= used"), the item is important or doesn't exist.


11. The text states: "Authorization Server (AS)=C2=A0= Manages the requested delegations for the RO". This is only one of two possibilities.
=C2=A0=C2=A0=C2=A0=C2=A0 The interaction between a = RO and an AS should be considered as an option. If a RO needs to interact, for privacy reasons, it should preferably
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interact with the RS= only.

[FI] The problem with working at the RS level is that it makes the integration harder (we don't exactly know what people will implement).
As a consequence, I would be in favor of an optional separation of that issue in an Interact Server, which could be distinct from the AS to alleviate privacy concerns.

[Denis] My point was/is about the quoted sentence: "Authorizati= on Server (AS)=C2=A0 Manages the requested delegations for the RO" = which is incorrect in the general case.
Furthermore, interactions with a RO create delays in the protocol, so I am favouring situations where a RO does not need to interact at all, in order to obtain a better throughput.
Anyway, I am not in favour of introducing a new entity like "an Interact Server".

[FI2] the IS is possibly just a part of the AS that deals with front-e= nd requirements. And in case people would like to implement privacy require= ments without the 10 step process described above where the RS needs to be = compatible, separating the=C2=A0AS and the IS seems like a viable option.= =C2=A0
I see no other way that doe= sn't add additional dependencies that we don't control.=C2=A0


12. The text states: "Resource=C2=A0 A protect= ed API served by the RS and accessed by the RC. Access to this resource is delegated by the RO as part of the grant process".
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The second part of t= he sentence should be deleted since a RO is not necessarily involved in the grant process.

[FI]=C2=A0=C2=A0Yes, more generally we should check that we can deal with user =3D RO (usually considered as the default case) and user !=3D RO (not often carefully designed).
I think the text already goes into much more details than OAuth2 for this (cf sequences 1.4).=C2=A0

[Denis] My preference is to use the term "end-user" for th= e entity interacting locally with the RC.

[FI2] same for me=C2=A0



13. The text states: "Resource Client (RC, aka "client= ")=C2=A0 Requests tokens from the AS and uses tokens at the RS.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An instance of the R= C software is identified by its key, which can be known to the AS prior to the first request".

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is confusing. T= he key does not necessarily identify an instance of the RC software.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An instance of the R= C software uses a binding key which (for privacy reasons) should be dynamic but which may alternatively be static.

[FI] The client instance solves those issues.=C2=A0Might need to update the way it is describ= ed in the text.

[Denis] Let us have a look at the text in a subsequent version.

<= /div>
[FI2] there's PR132 on t= hat=C2=A0

1= 4. For privacy reasons, calls from an RS to an AS, such as token introspection, should be avoided.

[FI] Token introspection (as well as other aspects related to token management) should be reviewed in depth, currently we don't solve many of the problems we=C2=A0see in the OAuth world.
I don't believe calls from an RS to an AS should be avoided though, on the contrary there might be an alternative to your proposal where the RS could use a public AS endpoint for the revocation list.

[Denis]=C2=A0 In the single sentence above, I am not proposing a scenario "where the RS could use a public AS endpoint for the revocation list". My belief is that revocation should not be handled at all,
by using "short" validity periods for access tokens. By &qu= ot;short", I mean a duration of about 12 hours.

[FI2] well, that's one way of doing it, it would s= implify some things. But the problem (and a big one) is that if you have no= revocation mechanism, there's no way to implement sessions, and that&#= 39;s what many people are actually trying to do.=C2=A0=C2=A0


15. Section 2 deals with the parameters when making calls from a RC to an AS. This section would need to be revisited.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hereafter are only s= ome (of many) concerns about the current text. The most important is to identify which parameters shall be used
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and may be used when= making a call to get an access token.

=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "resources=C2=A0 Describes the rights that the RC is requesting for one or more access tokens to be used at RS=E2=80=99s.
=C2=A0=C2=A0=C2=A0=C2=A0 Section 2.1". Then af= ter: "Each object contains a "type" property that determine= s the type of API that the RC is calling.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (...)=C2=A0 The value of this field is under the control of the AS.

[FI] please provide your input to the terminology work.

=C2=A0[Denis] Would you be able to post to the list where we are now= , or a link where we can have an overview of the current proposed definitions ?

= [FI2] yes of course.=C2=A0
See :
- the process related to terminolog= y=C2=A0https://mailarchive.ietf.org/arch/msg/txauth/XfeobMcrycw4= TEAIOUkX0El1EWo/=C2=A0=C2=A0=C2=A0
- yesterday's email=C2=A0https://mailarchive.ietf.org/a= rch/msg/txauth/fA0KjzAriINGIIzjLmR3OAHiOqs/ (my proposal, from our disc= ussion above there are some differences, and that will be interesting to di= scuss)
<= p>


=C2=A0=C2=A0=C2=A0=C2=A0 The value of this field should not be under the control of the AS but of the RS.

[FI] ultimately, the field needs to correspond to what the RS provides, even if the AS is the one that generates the access token.=C2=A0
Your proposal is interesting but that would put more effort on the RS side, with impacts on deployability.=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "act= ions=C2=A0 The types of actions the RC will take at the RS". This is needed when capabilities are being used but not needed
=C2=A0=C2=A0=C2=A0=C2=A0 for the other cases. Revea= ling actions to an AS is against the user's privacy.

[FI] technically this could be any alias defined by the RS. Remember we discussed RS hiding strategies (ex: concealed identifier) which solve that issue.

=C2=A0[Denis] A key difference between an ACL scheme and a capabilit= y scheme is the following:

  • =C2=A0for an ACL scheme, the AS does not need to have any prior relationship with the RS (which is an advantage from a privacy point of view).
  • =C2=A0for a capability scheme, the capabilities needs to be defin= ed by the RO of each RS, either prior to the time of the access token request
    =C2=A0or at latest at the time of the access token request (which creates a delay).

=C2=A0=C2=A0=C2=A0=C2=A0 The text states: "locations= =C2=A0 The location of the RS as an array of strings. These strings are typically URIs identifying the location of the RS."=C2= =A0


=C2=A0=C2=A0=C2=A0=C2=A0 It is typically URLs (not = URIs) but it may also be service names so that an access token can be delegated by a first RS to a second RS
=C2=A0=C2=A0=C2=A0=C2=A0 belonging to the same serv= ice without the need for the first RS to request another access token.

[FI] delegation from a RS to another is a topic in itself, yet to be explored. I remember you sent various inputs on that, we might need to review them in detail.

[Denis] Using services names instead of URLs is not necessarily related to "delegation from a RS to another". If a RC can g= et such an access token, it may decide
to send it to any RS belonging to that service at any point of time. So this is relevant for the simple case without considering "delegation from a RS to another RS".

Denis



--000000000000dabf4605b5f20d3d-- From nobody Tue Dec 8 09:48:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F4B3A1065 for ; Tue, 8 Dec 2020 09:47:58 -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 DXZvx3F3EHxE for ; Tue, 8 Dec 2020 09:47:57 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 EC8B63A1068 for ; Tue, 8 Dec 2020 09:47:56 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id p126so20258212oif.7 for ; Tue, 08 Dec 2020 09:47:56 -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=DBSP2Hlx4lPKevuP8wpYCiQ7A6TgOxPeyCjcRIdhAbg=; b=c2xf08wditvM6gUS5POZI2U5y01Mp46OfAeYOUCa6nwQB1pYDKtFnmE1K1r5NojsrO YG9CEGpcy+D3IEUVW2ZBIHttA+kloIenSF+fzMKKD0j1fAD22heoPgWpxVDmrO/sIoQv odwI4br6iyVw6jSN4i7AobiFfmL7H1l9i4HxM4G9CnlWL2QYZqhz3p/+4pASLE5OX+8z Ccyqst4GorkfAF4QGTAIAXe+v/XSz+UIIv0/HY6VzCbwtQEyJO3qApltXyuSgewJBuDu GOvsMtydIEM+HAqFPsroHqsQS44cCPzM7W38Xp7F3QfkhvT1nhF5Ty9rE+nA+CMe3ghH OkbA== 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=DBSP2Hlx4lPKevuP8wpYCiQ7A6TgOxPeyCjcRIdhAbg=; b=MiA4pwAN5EFopbxTMpXAVgE0P5XxEvPOTLfeqFTNJkOLtaOenek0ZLGAIxOQX3X1EI QSSXEXAcGweoYKSOrgmjLuElENHxaclq9/y5xO6b07H8cxYiBGLht/c7ILqOEfl7fMWp FOw9PcRAjQA8XFQQPOFZ1oXasP+tJ/NYFxaXGgql82P/EWTKkjDmSUh0H7ZmwUpy6FGY 9W5/JT+j4eKV+5+ZiQk7fI1EfC96w2WT6Me7ooNZd/dn331MV6Q3m2nxiw2CsG6kqx6m FE9u3wOGz+T2LuXJX2rLtITIOuTszdR1emMQhSVLbCUsWzcG257AYpEaO1mUaEQDmNlM Y8sg== X-Gm-Message-State: AOAM532SIWFRENIg9tEcStduDvHsJlbDGIOEnlprUf75bLZuIAbBwFbI ipgXgHm2VDXF3zKDZCzOmErFfjVDZO5sR6YlB0ujWpobna771Q== X-Google-Smtp-Source: ABdhPJxkrWjo20XKtaC7yKNG3YAbx1QG7WP/A9PfsMuUR3K9xTYi1IezRzyV8C0Z73b1bTXtpRAF75Qlz0ZCr6yU2iU= X-Received: by 2002:aca:1109:: with SMTP id 9mr2425886oir.131.1607449675788; Tue, 08 Dec 2020 09:47:55 -0800 (PST) MIME-Version: 1.0 From: Tom Jones Date: Tue, 8 Dec 2020 09:47:44 -0800 Message-ID: To: txauth gnap Content-Type: multipart/alternative; boundary="000000000000eb765405b5f78a41" Archived-At: Subject: [GNAP] MTLS and 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: Tue, 08 Dec 2020 17:47:58 -0000 --000000000000eb765405b5f78a41 Content-Type: text/plain; charset="UTF-8" Before I pull the plug on this spec, I would like to check that my understanding is correct. Section 2.3.2 seems to say that the RC key used for signing is the TLS key. IE token binding is built into the core of the spec. I have made my feelings clear about token binding here https://tcwiki.azurewebsites.net/index.php?title=Token_Binding I will not use nor recommend the use of any spec that requires token binding. Peace ..tom --000000000000eb765405b5f78a41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Before I pull the plug on this spec, I would like to check= that my understanding is correct.

Section 2.3.2 seems t= o say that the RC key used for signing is the TLS key. IE token binding is = built into the core of the spec.

I have made my fe= elings clear about token binding here=C2=A0https://tcwiki.azurewebsites.n= et/index.php?title=3DToken_Binding

I will not = use nor recommend the use of any spec that requires token binding.

Peace ..tom
--000000000000eb765405b5f78a41-- From nobody Tue Dec 8 10:08:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F30C3A1080 for ; Tue, 8 Dec 2020 10:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mERpfVwlmoeI for ; Tue, 8 Dec 2020 10:08:14 -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 417AF3A10E9 for ; Tue, 8 Dec 2020 10:07:59 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B8I7vhZ005805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Dec 2020 13:07:57 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8A9DBEA5-D21F-4BB5-85FC-7CC50104CA98" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 8 Dec 2020 13:07:57 -0500 In-Reply-To: Cc: txauth gnap To: Tom Jones References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] MTLS and 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: Tue, 08 Dec 2020 18:08:16 -0000 --Apple-Mail=_8A9DBEA5-D21F-4BB5-85FC-7CC50104CA98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tom, Your reading is partially correct but has several fundamental = misconceptions that I hope I can help clear up.=20 First: the key used is not assumed to always be the client software=E2=80=99= s TLS key. Token binding is not required. Most keep proofing methods, all defined in section 8, happen up at the = application and HTTP layer. For these, you=E2=80=99d expect the key to = be different from anything on the TLS layer.=20 The one exception is the Mutual TLS key proofing method in section 8.3, = but importantly, this does not use =E2=80=9Ctoken binding=E2=80=9D in = the way that your linked web page talks about and doesn=E2=80=99t use = any of the token binding suite of TLS and HTTP extensions. It doesn=E2=80=99= t require any special support in browsers or libraries. Instead, it = works like the OAuth 2 Mutual TLS (RFC 8705) spec: the client simply = presents its key at the TLS layer and presents the token at the = application layer. Then it=E2=80=99s up to the AS or RS to determine if = the presented token is tied to the same key used in TLS. This is a = drastically simplified pattern compared to Token Binding and it=E2=80=99s = seen success in deployments because of that. The market failure of Token Binding, as referenced on your webpage, = therefore has no bearing on the method used here. And more importantly: support for multiple key proofing mechanisms is = fundamentally important enough to this group that it=E2=80=99s in the = charter several times as a major topic. MTLS makes sense for some = deployments, and really doesn=E2=80=99t for others. For example if = you=E2=80=99ve got browser-based client software, MTLS is a horrible = choice for both support and usability. But if you=E2=80=99ve got tightly = controlled back-end systems talking to each other, MTLS becomes a lot = more reasonable. We see the same patterns and the need for choice in the = OAuth world as well, and so mandating that everybody use one key = proofing mechanism would be a deep failure of this protocol. =E2=80=94 Justin > On Dec 8, 2020, at 12:47 PM, Tom Jones = wrote: >=20 > Before I pull the plug on this spec, I would like to check that my = understanding is correct. >=20 > Section 2.3.2 seems to say that the RC key used for signing is the TLS = key. IE token binding is built into the core of the spec. >=20 > I have made my feelings clear about token binding here = https://tcwiki.azurewebsites.net/index.php?title=3DToken_Binding = >=20 > I will not use nor recommend the use of any spec that requires token = binding. >=20 > Peace ..tom > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_8A9DBEA5-D21F-4BB5-85FC-7CC50104CA98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tom,

Your reading is = partially correct but has several fundamental misconceptions that I hope = I can help clear up. 

First: the key used is not assumed to always be the client = software=E2=80=99s TLS key. Token binding is not required.

Most keep proofing = methods, all defined in section 8, happen up at the application and HTTP = layer. For these, you=E2=80=99d expect the key to be different from = anything on the TLS layer. 

The one exception is the Mutual TLS key = proofing method in section 8.3, but importantly, this does not use = =E2=80=9Ctoken binding=E2=80=9D in the way that your linked web page = talks about and doesn=E2=80=99t use any of the token binding suite of = TLS and HTTP extensions. It doesn=E2=80=99t require any special support = in browsers or libraries. Instead, it works like the OAuth 2 Mutual TLS = (RFC 8705) spec: the client simply presents its key at the TLS layer and = presents the token at the application layer. Then it=E2=80=99s up to the = AS or RS to determine if the presented token is tied to the same key = used in TLS. This is a drastically simplified pattern compared to Token = Binding and it=E2=80=99s seen success in deployments because of = that.

The = market failure of Token Binding, as referenced on your webpage, = therefore has no bearing on the method used here.
And more importantly: support for = multiple key proofing mechanisms is fundamentally important enough to = this group that it=E2=80=99s in the charter several times as a major = topic. MTLS makes sense for some deployments, and really doesn=E2=80=99t = for others. For example if you=E2=80=99ve got browser-based client = software, MTLS is a horrible choice for both support and usability. But = if you=E2=80=99ve got tightly controlled back-end systems talking to = each other, MTLS becomes a lot more reasonable. We see the same patterns = and the need for choice in the OAuth world as well, and so mandating = that everybody use one key proofing mechanism would be a deep failure of = this protocol.

 =E2=80=94 Justin

On Dec = 8, 2020, at 12:47 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

Before I pull the plug on this = spec, I would like to check that my understanding is correct.

Section 2.3.2 seems to = say that the RC key used for signing is the TLS key. IE token binding is = built into the core of the spec.

I have made my feelings clear about = token binding here https://tcwiki.azurewebsites.net/index.php?title=3DToken_Bindin= g

I will = not use nor recommend the use of any spec that requires token = binding.

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

= --Apple-Mail=_8A9DBEA5-D21F-4BB5-85FC-7CC50104CA98-- From nobody Tue Dec 8 10:38:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D703A10A9 for ; Tue, 8 Dec 2020 10:38: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 tQV8IhcSSYcv for ; Tue, 8 Dec 2020 10:38:39 -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 E57803A10A7 for ; Tue, 8 Dec 2020 10:38:38 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id j12so9227964ilk.3 for ; Tue, 08 Dec 2020 10:38: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=4CH/p40EaYyW9yZ7JGKXCnpymRd70NK2hTwNs8FdeP8=; b=DchDVHc3DakktqWHYN2eo5NI74IZ5HAJbTPE6C83CxJi7taZsvqoubHUD6oPOUajPl wkteSnawJGfLEZCsPJeRw9yBIRu15V8RDMFdEjfFhlib+BRgyRIbenxmpFvqf3vugK2S WDyMprFQUsXqsqyElpNP6T+Ly/kE+bT073hlWZ5Za8pvqyCtrvIn3DX6IPVVnboB1Q5p DUYwfUe1+0TkljDXow2T/60xcU9YCbpImv/TMs5RhTHa8CO/wvG9hTixHTcKMqsheymm fkmiByP6J097TIHjcTr55KQn4wfem9EnOWfRxLhpyNv9s1MZE+VcfsCNbbwWW6QA4mIZ pGjw== 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=4CH/p40EaYyW9yZ7JGKXCnpymRd70NK2hTwNs8FdeP8=; b=MFvlVa0smrC4FLp1SYEOCEPSrAuVPwH35g9XEsd61wao0RgW3MUZ29sHssaWtLBXF1 8pBzngIjeNYTmLtfEedNIh9JlBf1ZyF4S5RgadEgEMrxpTW8pVoMKglWGtqyX7AxUobc Rfwqu5GCVJS0/lLpOR/QnJtoNc4TkdASSb7kLyJ78FaOSbxjH0SpNGpch2ue9IhawRd6 rUEUCF6k7t4pnu2l7Nsn8BeQcdH5e6ohk+CdFVrVD1V4QcvLW2Y+LgxJTda9UFF8OIdB NG/pg5P5H/tXk4KPCw7vVZxuDu+OLKZ9ZUON76d2rvu8T72czZSuNCkh8o74Vc8/5u/D Lsjg== X-Gm-Message-State: AOAM533A+4y9zjunPeGNcQNV+XfpKQa0qcPc/wpPCTHcKPmb9qQpCS/0 AzndhKORxZ6E9mKfnpcpF9L15qiRE8Biouyx0o4= X-Google-Smtp-Source: ABdhPJy16icwJKT239WlFGl4x6QoEuDJPeaFAjW95Kk0sD2BU+QCAWGrlZOv/C52IGhftb3WsSzYW5rINOwWa37Nmj4= X-Received: by 2002:a92:d34c:: with SMTP id a12mr13822050ilh.188.1607452718092; Tue, 08 Dec 2020 10:38:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Tue, 8 Dec 2020 19:38:25 +0100 Message-ID: To: Justin Richer Cc: Tom Jones , txauth gnap Content-Type: multipart/alternative; boundary="00000000000041586705b5f840fa" Archived-At: Subject: Re: [GNAP] MTLS and 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: Tue, 08 Dec 2020 18:38:41 -0000 --00000000000041586705b5f840fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, Please also keep in mind that section 8 is still to be investigated in full. So in case you have different opinions, you'll be able to provide your inputs. It seems quite clear that different use cases (as documented on the wiki) require different key proofing mechanisms, and the fact that GNAP makes it flexible should ease your concerns. Cheers Fabien On Tue, Dec 8, 2020 at 7:08 PM Justin Richer wrote: > Hi Tom, > > Your reading is partially correct but has several fundamental > misconceptions that I hope I can help clear up. > > First: the key used is not assumed to always be the client software=E2=80= =99s TLS > key. Token binding is not required. > > Most keep proofing methods, all defined in section 8, happen up at the > application and HTTP layer. For these, you=E2=80=99d expect the key to be= different > from anything on the TLS layer. > > The one exception is the Mutual TLS key proofing method in section 8.3, > but importantly, this does not use =E2=80=9Ctoken binding=E2=80=9D in the= way that your > linked web page talks about and doesn=E2=80=99t use any of the token bind= ing suite > of TLS and HTTP extensions. It doesn=E2=80=99t require any special suppor= t in > browsers or libraries. Instead, it works like the OAuth 2 Mutual TLS (RFC > 8705) spec: the client simply presents its key at the TLS layer and > presents the token at the application layer. Then it=E2=80=99s up to the = AS or RS > to determine if the presented token is tied to the same key used in TLS. > This is a drastically simplified pattern compared to Token Binding and it= =E2=80=99s > seen success in deployments because of that. > > The market failure of Token Binding, as referenced on your webpage, > therefore has no bearing on the method used here. > > And more importantly: support for multiple key proofing mechanisms is > fundamentally important enough to this group that it=E2=80=99s in the cha= rter > several times as a major topic. MTLS makes sense for some deployments, an= d > really doesn=E2=80=99t for others. For example if you=E2=80=99ve got brow= ser-based client > software, MTLS is a horrible choice for both support and usability. But i= f > you=E2=80=99ve got tightly controlled back-end systems talking to each ot= her, MTLS > becomes a lot more reasonable. We see the same patterns and the need for > choice in the OAuth world as well, and so mandating that everybody use on= e > key proofing mechanism would be a deep failure of this protocol. > > =E2=80=94 Justin > > On Dec 8, 2020, at 12:47 PM, Tom Jones > wrote: > > Before I pull the plug on this spec, I would like to check that my > understanding is correct. > > Section 2.3.2 seems to say that the RC key used for signing is the TLS > key. IE token binding is built into the core of the spec. > > I have made my feelings clear about token binding here > https://tcwiki.azurewebsites.net/index.php?title=3DToken_Binding > > I will not use nor recommend the use of any spec that requires token > binding. > > Peace ..tom > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000041586705b5f840fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

Please also = keep in mind that section 8 is still to=C2=A0be investigated in full. So in= case you have different opinions, you'll be able to provide your input= s.=C2=A0 =C2=A0
It seems quite clear that different use cases= (as documented on the wiki) require different key proofing mechanisms, and= the fact that GNAP makes it flexible should ease your concerns.=C2=A0=C2= =A0

Cheers
Fabien=C2=A0=C2=A0
=

On Tue, Dec 8, 2020 at 7:08 PM Justin Richer <jricher@mit.edu> wrote:
Hi = Tom,

Your reading is partially correct but has several f= undamental misconceptions that I hope I can help clear up.=C2=A0
=
First: the key used is not assumed to always be the client s= oftware=E2=80=99s TLS key. Token binding is not required.

Most keep proofing methods, all defined in section 8, happen up at = the application and HTTP layer. For these, you=E2=80=99d expect the key to = be different from anything on the TLS layer.=C2=A0

The one exception is the Mutual TLS key proofing method in section 8.3, bu= t importantly, this does not use =E2=80=9Ctoken binding=E2=80=9D in the way= that your linked web page talks about and doesn=E2=80=99t use any of the t= oken binding suite of TLS and HTTP extensions. It doesn=E2=80=99t require a= ny special support in browsers or libraries. Instead, it works like the OAu= th 2 Mutual TLS (RFC 8705) spec: the client simply presents its key at the = TLS layer and presents the token at the application layer. Then it=E2=80=99= s up to the AS or RS to determine if the presented token is tied to the sam= e key used in TLS. This is a drastically simplified pattern compared to Tok= en Binding and it=E2=80=99s seen success in deployments because of that.

The market failure of Token Binding, as referenced o= n your webpage, therefore has no bearing on the method used here.

And more importantly: support for multiple key proofing mec= hanisms is fundamentally important enough to this group that it=E2=80=99s i= n the charter several times as a major topic. MTLS makes sense for some dep= loyments, and really doesn=E2=80=99t for others. For example if you=E2=80= =99ve got browser-based client software, MTLS is a horrible choice for both= support and usability. But if you=E2=80=99ve got tightly controlled back-e= nd systems talking to each other, MTLS becomes a lot more reasonable. We se= e the same patterns and the need for choice in the OAuth world as well, and= so mandating that everybody use one key proofing mechanism would be a deep= failure of this protocol.

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

On Dec 8, 2020, at 12:47 = PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

Before I pull the plug on this spec, I would like to check that my= understanding is correct.

Section 2.3.2 seems to say th= at the RC key used for signing is the TLS key. IE token binding is built in= to the core of the spec.

I have made my feelings c= lear about token binding here=C2=A0https://tcwiki.azure= websites.net/index.php?title=3DToken_Binding

I= will not use nor recommend the use of any spec that requires token binding= .

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

--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000041586705b5f840fa-- From nobody Wed Dec 9 10:18:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375B53A16E2 for ; Wed, 9 Dec 2020 10:18:13 -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_40=-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 cPw-spwtwCVa for ; Wed, 9 Dec 2020 10:18:08 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 221473A16E1 for ; Wed, 9 Dec 2020 10:18:08 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id f132so2683693oib.12 for ; Wed, 09 Dec 2020 10:18:08 -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=SXDZFjOx4T1f5XU/kJESMef179uOt3mqfcVedZ+wQas=; b=LBjtD1/APPxetQxlnsy0QbUpTP0AkgRjwCLgqKqIPOJLd2VVABgrK8fRwyubVJNJE9 F0ge7RNdwg8mky/hKqUTeN+L7mv4s7gy3/ZEBrXVB/ZJ0BE9p3ePiM9ySQ9xBl1DtTPH cxzYuOgmRf3Fi4/HxOWUMve5JQAFgq4o+iAp4r/95MmoibcYN0k46SmKqnkPUTlXibsS YDRhEk07MjEZhBjvU3tBSF2wHxZ/Y5Y6J04zApGYT2LwYEm9++aoCTu9FoQknIAv+PaY xqy2ijIIHwLcolAWpQ7gx7K0WYr+acjzWyQcQ9dSKCRG97qO+DPWvHtE8Fwu14ZkQKpT 9ddw== 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=SXDZFjOx4T1f5XU/kJESMef179uOt3mqfcVedZ+wQas=; b=unE6SDHrg1FkQTaXkGEZOjHpcXJl3Zkeuma1oWyGN5GaNDTRVfIEuar8ctsX/qqClB sUBLlaIQo3E3/BoCebCR0vGl/3ZMr8XONONb/1+tlNh51VuT1VKiqi6ByRUZAGdV3UFf zHAapgBsz9RYFJ7JTBWaw4TPBbe1xXZxgKaklPR8x54ig9TZJOWAIT/kAyHxmfOwZhey 4d1XGLpkXx61G3hKQj7brCrPvK6h6SgW14CCC52DPywzde+GXipQxTGSlMfXc4Zt0BKq C7v0P0xeeSrCqmrqrUdkMJEj1VIfonBCPCxO9rmGzRXGjVGAKbEoKTad9XcqYF1TRR9S K7mQ== X-Gm-Message-State: AOAM530VD8DKZfAXwA/oVr+xGE8m7a+mit+GZjb717zzI95ocJp2ZtO5 VM+To46YM2I+dhYVcBNdc55Fc/dFDwQoPS/0vR5I0SA+nw8= X-Google-Smtp-Source: ABdhPJyGOzbZWOIVeQKod6aY9CcfnR3rkMuQxsLI61tnfT8D2j8NuHQ2gNCP908okCgn0W53e1zQGKSP3pwXqxDqu0Y= X-Received: by 2002:aca:47cb:: with SMTP id u194mr2738308oia.63.1607537886706; Wed, 09 Dec 2020 10:18:06 -0800 (PST) MIME-Version: 1.0 From: Tom Jones Date: Wed, 9 Dec 2020 10:17:54 -0800 Message-ID: To: txauth gnap Content-Type: multipart/alternative; boundary="000000000000b3416e05b60c144f" Archived-At: Subject: [GNAP] RO statement is not always true 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, 09 Dec 2020 18:18:13 -0000 --000000000000b3416e05b60c144f Content-Type: text/plain; charset="UTF-8" That is it is often false which is why i dislike the term RO. Often the the data about the subject was created by the RS and can be bound by law not to delete it. *Resource Owner (RO)* Authorizes the request to access a protected resource from the RS to the client. The RO may decide to remove its consent at any time. Note : the RO may be a physical person or may represent an organization. thx ..Tom (mobile) --000000000000b3416e05b60c144f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is it is often false which is why i dislike the term= RO. Often the the data about the subject was created by the RS and can be = bound by law not to delete it.

<= font color=3D"#24292e">Resource Owner (= RO)

Authorizes the request to access a prote= cted resource from the RS to the client. The RO may decide to remove its co= nsent at any time.

Note : the RO may be a physical perso= n or may represent an organization.

thx ..Tom (mobile)
--000000000000b3416e05b60c144f-- From nobody Wed Dec 9 10:35:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275893A10CB for ; Wed, 9 Dec 2020 10:35: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 KDkRrrotEPB3 for ; Wed, 9 Dec 2020 10:35:01 -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 39BC13A1093 for ; Wed, 9 Dec 2020 10:35:01 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id 81so2626203ioc.13 for ; Wed, 09 Dec 2020 10:35: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=hf+KsZXIBIXclsau6PNNC3CTBdTH5Q8NJYjxKzVN0rM=; b=JnDchZSltr4tVHYScDFwtFzYXQSDhkj9IJC9gH+sp+1xQuQC0QKcHuOZ/fg+HdRZIf RwLEG6ZjgfqfVmr1CejceoHxKBaGsqkXJAvOUs1zZbZesANwKJlbCq8qsX9uUp2YBsyU NWg9j2Ng6M5WvjfeJuiYDd8DMzPviki1WIdDp+aQYIB+9haTG/PR9SlJ+t9wQ/fp97ze ubRpJ5ozXT/DyAUvN3ha9kamCibsqBzocAj95pGOiAk22/NdRLy3d4eairZ0U1MGPpPU QBvriSAjtuvmwFheWjFqB7MIfd9/9LhZbKu4TF7sjPCQ95xlcGJoDEh5M67nYtS1WKA4 nn5g== 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=hf+KsZXIBIXclsau6PNNC3CTBdTH5Q8NJYjxKzVN0rM=; b=N7FzCghSFy1iuCb/fhRUkkHn/sJHjRWoPA8eqxcFNmI3caD1c9aHuTiwW06sAJec1N PmP885Gqo1WE6VLiMHFFmdK6VwuHRrZL96/iUH4ev44zw4El99x8kDiuiDBUpzD5Oiux 4hubQ9avjKI5LUt3fpnk8bDaxGNRNvuvpx/vKKctxa1g/3vtznD65Igix4840gPrqkcE hZuWUsoO8f6e35wUD5yD6kCKhR5kOJzMGncHEuj3njmNNHIgwjkakRlcqhgMb2HV/k/P cxIu6eFFkakNACzBgSlLIw1xT0hHvQV4gEpxuprUB63vS8GwQFoH/foggjKm4bbAvlkB iCag== X-Gm-Message-State: AOAM531+0RoTrOn4yYPADKFTbPIpZBaFb55NxH8p5Wc0BRJpOaTEAqBb q+djprM9qOBa/hT/gSvG/WSb/SmuV7mRHLhCBeo= X-Google-Smtp-Source: ABdhPJwyjriePmAIfP6GZ7ztmnwtTaqibS1X0bQhtI3+glrJUeFl9tPH6Cs7SiH/3F06mi5zqbArqjxPCojSx1vWwqI= X-Received: by 2002:a02:5148:: with SMTP id s69mr4858914jaa.8.1607538900428; Wed, 09 Dec 2020 10:35:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 9 Dec 2020 19:34:49 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="0000000000001f6a7805b60c5191" Archived-At: Subject: Re: [GNAP] RO statement is not always true 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, 09 Dec 2020 18:35:03 -0000 --0000000000001f6a7805b60c5191 Content-Type: text/plain; charset="UTF-8" Hello Tom, Thanks for the feedback. Yes that's true, but keeping the data is a distinct issue from consenting access (and removing access to some end-user). Except of course if we're discussing specific actions, such as a delete. When created by the RS, the RO merely represents a role of the RS. So overall, even if your comment is spot on, the definition itself doesn't prevent what you're describing. What alternative would you propose that would explain it better ? (but of course if we change a commonly used vocabulary, there's a lot more convincing to do). Best Fabien On Wed, Dec 9, 2020 at 7:18 PM Tom Jones wrote: > That is it is often false which is why i dislike the term RO. Often the > the data about the subject was created by the RS and can be bound by law > not to delete it. > *Resource Owner (RO)* > > Authorizes the request to access a protected resource from the RS to the > client. The RO may decide to remove its consent at any time. > > Note : the RO may be a physical person or may represent an organization. > thx ..Tom (mobile) > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001f6a7805b60c5191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Tom,=C2=A0

Thanks for = the feedback.

Yes that's true, but keeping the data= is a distinct issue from consenting access (and removing access to some en= d-user). Except of course if we're discussing specific actions, such as= a delete.=C2=A0 =C2=A0
When created by the RS, the RO merely represent= s a role of the RS.=C2=A0
So overall, even if your comment is spo= t on, the definition itself doesn't prevent what you're describing.=

What alternative would you propose that=C2=A0woul= d explain it better ? (but of course if we change a commonly=C2=A0used voca= bulary, there's a lot more convincing to do).=C2=A0

Best
Fabien

On Wed, Dec 9, 2020 at 7:18 PM Tom Jones &= lt;thomasclinganjones@gmail= .com> wrote:
That is it is often false which is why i dislike the = term RO. Often the the data about the subject was created by the RS and can= be bound by law not to delete it.

Resource Own= er (RO)

Authorizes the request to access a p= rotected resource from the RS to the client. The RO may decide to remove it= s consent at any time.

Note : the RO may be a physical p= erson or may represent an organization.

thx ..Tom (mo= bile)
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000001f6a7805b60c5191-- From nobody Wed Dec 9 10:44:22 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF603A16FC for ; Wed, 9 Dec 2020 10:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiDA7cmLDLK8 for ; Wed, 9 Dec 2020 10:44:10 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 B7F813A1738 for ; Wed, 9 Dec 2020 10:44:10 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id b18so2388222ots.0 for ; Wed, 09 Dec 2020 10:44:10 -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=xG4wa3h75JQiggHxoZnE744SjjAF9KYdawpwNusD3tM=; b=tm4sZqQC6yv7IJOJCPofxRpubWmXgPlzOoZqOl91jx/N78+TcIdUlf1BQalWUtXzmY cZpv3PUHRaonp4N303q9YeT87eJAMRF9VO9pGNHMpHL45XQehVCBS+FGsUdacWtWXdMj 0nJy96XdwaX4Ytr3qMH9cfKgcWdxN0SIb6E6jT2C1Z4v4KN5wc9DSx8moHaRTbyjztB8 pMY8VYXLiubDiK/EodENnTEeKUk1WT8Rxc1hc8T7M4lb3V7BFTboJdP6+seNmezaRM34 kWBtP7lfnp2hbLu2EDLkI7kig6AtH9eKpe9Isaxjh4sN0Mf54WQmfeGpZ9Nhkk909C5e ADhg== 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=xG4wa3h75JQiggHxoZnE744SjjAF9KYdawpwNusD3tM=; b=D/o8XcdB2DRarunKMFBZqcfLUIFV/SmG95LZLIrQB6kblTle8kLimkwQuNUIA7Cpnb WRj7/NBf3v9CbleYA+ejxe5EGot9AQ2ontBgE3lffjB8YERPsMH8yzDy10xyg80pFOAF zGy9FGIGXSApG91v29N/nO7VgWoCkYMMtH87E3GVBm/4FeY6j5bQ5BPMg0NYxJNIMyoD d9UD16+dhOg230xfD9lSthX4RWcAuiHbvMgF3bfeET81JqHpsRMK4+7S30emYfws6Wwb eIyGvi4GgtNhvB6UNqcfNlmGjmPkgh4OVFA6meLZAhxRnVcLcaEYBDiJW547Cdt+MBeS UL8w== X-Gm-Message-State: AOAM531bc6FaeJYIexsso3C50+/t8bbTlkMetdJXoQi3JyRu4q9x8aB2 xWdS1s90UoOjotkYsIAo6FYKY4zWstzpslYfz5s= X-Google-Smtp-Source: ABdhPJzd1Rh8iUmOI8uTPgqQNcL4X+tMkPn4OzUKqIVTBPNGNWda/Nu7CSivut1ZfFYXgXRN/Jyw1gmw7bQiqUHhIx0= X-Received: by 2002:a9d:37c4:: with SMTP id x62mr1789970otb.87.1607539449813; Wed, 09 Dec 2020 10:44:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Wed, 9 Dec 2020 10:43:58 -0800 Message-ID: To: Fabien Imbault Cc: txauth gnap Content-Type: multipart/alternative; boundary="000000000000de5da105b60c71ec" Archived-At: Subject: Re: [GNAP] RO statement is not always true 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, 09 Dec 2020 18:44:21 -0000 --000000000000de5da105b60c71ec Content-Type: text/plain; charset="UTF-8" you could delete the sentence that is false. The RO may decide to remove its consent at any time. Perhaps you could say that The RO may be given a method to tell the AS to remove its consent. the way it is written the AS MUST have such an API. -->. or was that your intention? In any case such a statement belongs in a normative section NOT IN THE TAXONOMY!!! Peace ..tom On Wed, Dec 9, 2020 at 10:35 AM Fabien Imbault wrote: > Hello Tom, > > Thanks for the feedback. > > Yes that's true, but keeping the data is a distinct issue from consenting > access (and removing access to some end-user). Except of course if we're > discussing specific actions, such as a delete. > When created by the RS, the RO merely represents a role of the RS. > So overall, even if your comment is spot on, the definition itself doesn't > prevent what you're describing. > > What alternative would you propose that would explain it better ? (but of > course if we change a commonly used vocabulary, there's a lot more > convincing to do). > > Best > Fabien > > On Wed, Dec 9, 2020 at 7:18 PM Tom Jones > wrote: > >> That is it is often false which is why i dislike the term RO. Often the >> the data about the subject was created by the RS and can be bound by law >> not to delete it. >> *Resource Owner (RO)* >> >> Authorizes the request to access a protected resource from the RS to the >> client. The RO may decide to remove its consent at any time. >> >> Note : the RO may be a physical person or may represent an organization. >> thx ..Tom (mobile) >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000de5da105b60c71ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
you could delete the sentence=C2=A0that is false.=C2=A0=C2= =A0The RO may decide to remove its consent at any time.
<= font color=3D"#24292e" face=3D"arial, sans-serif">
Perhaps you could say that Th= e RO may be given a method to tell the AS to remove its consent.

the way it is = written=C2=A0the AS MUST have such an API. -->. or was that your intenti= on?
In any case such a statement belongs i= n a normative section NOT IN THE TAXONOMY!!!

Peace ..to= m


On Wed, Dec 9, 2020 at 10:35 AM Fabien I= mbault <fabien.imbault@gmail= .com> wrote:
Hello Tom,=C2=A0

Thanks = for the feedback.

Yes that's true, but keeping the = data is a distinct issue from consenting access (and removing access to som= e end-user). Except of course if we're discussing specific actions, suc= h as a delete.=C2=A0 =C2=A0
When created by the RS, the RO merely repre= sents a role of the RS.=C2=A0
So overall, even if your comment is= spot on, the definition itself doesn't prevent what you're describ= ing.

What alternative would you propose that=C2=A0= would explain it better ? (but of course if we change a commonly=C2=A0used = vocabulary, there's a lot more convincing to do).=C2=A0

<= /div>
Best
Fabien

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 9, 2020 at 7:18 PM Tom Jon= es <th= omasclinganjones@gmail.com> wrote:
That is it is often false which= is why i dislike the term RO. Often the the data about the subject was cre= ated by the RS and can be bound by law not to delete it.

Resource Owner (RO)

Authorizes the= request to access a protected resource from the RS to the client. The RO m= ay decide to remove its consent at any time.

Note : the = RO may be a physical person or may represent an organization.=

thx ..Tom (mobile)
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000de5da105b60c71ec-- From nobody Wed Dec 9 10:58:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DD53A16F8 for ; Wed, 9 Dec 2020 10:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Rx56UsKSyI for ; Wed, 9 Dec 2020 10:57:57 -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 306193A1667 for ; Wed, 9 Dec 2020 10:57:57 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id y5so2723971iow.5 for ; Wed, 09 Dec 2020 10:57: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=naXx+aRM+84jp1YSPVrlh3Enji4pdtZ3le7NJqNNTAc=; b=QBIxRw7WQb/ZjQmX5Ry0GtnNBzxyi6dXELNIU0Ie/6wxtuX3wfKDPRn9CC3GmkR6/7 2Bvk2N57rQlZmMWim8Db4Ku+NOcK4IM3XxO3hPIsUn7VwaFVxWBdm36E7rV1tNGhqX1G cmv2jT9HFYq8RhTYE5YdAInH/ZzZhGNuWqoR1BW9cl/wdciyavfeUolI+C4vT24+6GsR pdLbXOnJVVN8DeVhzwF0EtH/Lv8dUZ+jmrwYhmnr9IymT4DW7IQ+s6w7QryfT1WYTOwW NVFrsP7SlIlAuJwqPdEEz8Nl+QOBB2LqS8Ds3mkjS5IRTpwwdhlmVWKLroby7CShjaKr SJ2A== 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=naXx+aRM+84jp1YSPVrlh3Enji4pdtZ3le7NJqNNTAc=; b=Purla0Zlf0rWzM7VBkTxQmMI91f+PGQ8349ofYZ6HCnWb5ith5eZrId8m1tFLEgMKu uBtJPDB6gXhWYK6wriT8y4BPf8MgKAFmjPb39Vp/lnmsByKT0+Ss3YXDT3HNtWcreyXY Kf4qZp6U0DWEPhBkAAwA/lC8ejVkvLKkiyNjCVBo8W9uF6rRbqaGGWY7HVrrCofr9RoC NM4dwYb9+kIPN7Hi9DUzTb7GeBzfQcU7AT8/lnAKpbXlVeLlEcJ1tUjv9FBFc/Nla4aD YpBsGqkZVUpOoLbU0G9HH45RWcsTakwk4waUUlY+n78ZUtaxrIcbbZP3uWsK0XNErzJM i1eA== X-Gm-Message-State: AOAM531RklQd6XKlWisIP4HoMOiXafpST8xIsqFn5u6wY09kQuFenTTL OKCUX4CMMhu4kwCpNslc27k5nRBgjJEE8f29lvE= X-Google-Smtp-Source: ABdhPJz6qFQYt48L8l4ctJ44QTZtScF7KO+RJPz01ECuc3FSw8ADExSca6QFJX8DX031jtJAwel4nd3K7t7Fi0Tg+zE= X-Received: by 2002:a5d:85c7:: with SMTP id e7mr4587352ios.162.1607540276334; Wed, 09 Dec 2020 10:57:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 9 Dec 2020 19:57:43 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="0000000000002212bb05b60ca3c0" Archived-At: Subject: Re: [GNAP] RO statement is not always true 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, 09 Dec 2020 18:57:59 -0000 --0000000000002212bb05b60ca3c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The intent was not to make it mandatory, but you're right, it becomes a consequence. The intent was to remind end-users that the RO is in control of its consent decisions. Your alternative proposal looks fine to me. Thanks for spotting that. Fabien Le mer. 9 d=C3=A9c. 2020 =C3=A0 19:44, Tom Jones a =C3=A9crit : > you could delete the sentence that is false. The RO may decide to remove > its consent at any time. > > Perhaps you could say that The RO may be given a method to tell the AS to > remove its consent. > > the way it is written the AS MUST have such an API. -->. or was that your > intention? > In any case such a statement belongs in a normative section NOT IN THE > TAXONOMY!!! > > Peace ..tom > > > On Wed, Dec 9, 2020 at 10:35 AM Fabien Imbault > wrote: > >> Hello Tom, >> >> Thanks for the feedback. >> >> Yes that's true, but keeping the data is a distinct issue from consentin= g >> access (and removing access to some end-user). Except of course if we're >> discussing specific actions, such as a delete. >> When created by the RS, the RO merely represents a role of the RS. >> So overall, even if your comment is spot on, the definition itself >> doesn't prevent what you're describing. >> >> What alternative would you propose that would explain it better ? (but o= f >> course if we change a commonly used vocabulary, there's a lot more >> convincing to do). >> >> Best >> Fabien >> >> On Wed, Dec 9, 2020 at 7:18 PM Tom Jones >> wrote: >> >>> That is it is often false which is why i dislike the term RO. Often the >>> the data about the subject was created by the RS and can be bound by la= w >>> not to delete it. >>> *Resource Owner (RO)* >>> >>> Authorizes the request to access a protected resource from the RS to th= e >>> client. The RO may decide to remove its consent at any time. >>> >>> Note : the RO may be a physical person or may represent an organization= . >>> thx ..Tom (mobile) >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --0000000000002212bb05b60ca3c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The intent was not to ma= ke it mandatory, but you're right, it becomes a consequence. The intent= was to remind end-users that the RO is in control of its consent decisions= .=C2=A0

Your alternative= proposal looks fine to me.=C2=A0

Thanks for spotting that.=C2=A0
Fabien=C2= =A0

Le mer. 9 d=C3=A9c. 2020 =C3=A0 19:44, Tom Jones <thomasclinganjones@gmail.com&= gt; a =C3=A9crit=C2=A0:
you could delete the sentence=C2=A0that is false.=C2=A0=C2=A0T= he RO may decide to remove its consent at any time.
Perhaps you could say that The RO may b= e given a method to tell the AS to remove its consent.
<= div>
the way it is written=C2= =A0the AS MUST have such an API. -->. or was that your intention?=
In any case such a statement belongs in a normat= ive section NOT IN THE TAXONOMY!!!

Peace ..tom

<= /div>
O= n Wed, Dec 9, 2020 at 10:35 AM Fabien Imbault <fabien.imbault@gmai= l.com> wrote:
Hello Tom,=C2=A0

Thanks= for the feedback.

Yes that's true, but keeping the= data is a distinct issue from consenting access (and removing access to so= me end-user). Except of course if we're discussing specific actions, su= ch as a delete.=C2=A0 =C2=A0
When created by the RS, the RO merely repr= esents a role of the RS.=C2=A0
So overall, even if your comment i= s spot on, the definition itself doesn't prevent what you're descri= bing.

What alternative would you propose that=C2= =A0would explain it better ? (but of course if we change a commonly=C2=A0us= ed vocabulary, there's a lot more convincing to do).=C2=A0
Best
Fabien

On Wed, Dec 9, 2020 at 7:18 PM Tom = Jones <thomasclinganjones@gmail.com> wrote:
That is i= t is often false which is why i dislike the term RO. Often the the data abo= ut the subject was created by the RS and can be bound by law not to delete = it.

Resource Owner (RO)

Authorizes the request to access a protected resource from the RS t= o the client. The RO may decide to remove its consent at any time.

Note : the RO may be a physical person or may represent an organ= ization.

thx ..Tom (mobile)
--
TXAuth mailing list
TXA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--0000000000002212bb05b60ca3c0-- From nobody Thu Dec 10 07:52:11 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD173A1015 for ; Thu, 10 Dec 2020 07:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_DOTEDU_SHORT=2.499, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9lv-O5YWaMo for ; Thu, 10 Dec 2020 07:52:09 -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 EC3CB3A1013 for ; Thu, 10 Dec 2020 07:52:03 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BAFq1oX008375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 10 Dec 2020 10:52:01 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_BB19064D-1444-4107-A967-FD068DCCF23D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> Date: Thu, 10 Dec 2020 10:52:01 -0500 To: txauth gnap X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Consensus Call on Continuation Request 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, 10 Dec 2020 15:52:10 -0000 --Apple-Mail=_BB19064D-1444-4107-A967-FD068DCCF23D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The editors and chairs would like to confirm consensus on a current pull = request: https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 = This pull request simplifies the continuation response and request by = making the access token mandatory, and it clarifies the responsibilities = of the AS in enforcing the security of the continuation request. Several = WG members expressed specific support for keeping the access token to = enable specific use cases, and there was general support for simplifying = the process from what it currently is in the draft. The editors believe = the pull request represents a solution that meets these goals. This call is open until Monday December 14. At that point, the PR will = be merged unless the chairs determine there is not rough consensus for = its inclusion. Thank you, - Justin, Aaron, and Fabien= --Apple-Mail=_BB19064D-1444-4107-A967-FD068DCCF23D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = editors and chairs would like to confirm consensus on a current pull = request:

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

This pull = request simplifies the continuation response and request by making the = access token mandatory, and it clarifies the responsibilities of the AS = in enforcing the security of the continuation request. Several WG = members expressed specific support for keeping the access token to = enable specific use cases, and there was general support for simplifying = the process from what it currently is in the draft. The editors believe = the pull request represents a solution that meets these goals.

This call is open until = Monday December 14. At that point, the PR will be merged unless the = chairs determine there is not rough consensus for its = inclusion.

Thank= you,

 - = Justin, Aaron, and Fabien
= --Apple-Mail=_BB19064D-1444-4107-A967-FD068DCCF23D-- From nobody Thu Dec 10 12:06:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B582B3A12AB for ; Thu, 10 Dec 2020 12:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MM6TRFt3By6 for ; Thu, 10 Dec 2020 12:05:51 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9673A12FB for ; Thu, 10 Dec 2020 12:05:44 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id r24so10016342lfm.8 for ; Thu, 10 Dec 2020 12:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KC6lzulLNOZwdcqbQdyOC5RxU6ebFqK4gczLk4LkF+M=; b=ceoEhXCzkVY+O2U49n2saBm4+BIlSWmI8CWQVUqxdcWxQsGPEGXxGdIkpRQ4tZPpla zX/S9yVAGLrC3qoaeyn1sJpHJ8/fKNUN+lLYiP5OOhorUTUgOxcJOhch7a5pYX7l1eo2 ir/bWUOO/82c7Hrs/mRkSpcnBFFXwLVP4RZ6UvLclpMiL3xY2jQLRh9L4GUPCkSkMWFC BEFdMlNV1nEByttIsZAHUyNY7Ar1pG45GJZMWeTRlL5S0+1t+/FPpjSQFNMMPKkGR8JS ONVuMfcwRfQ0KIGypS2NDQn1wasIIB0kC74KwFp76leTIbv51xLI3S2fYf/TbCqeSPoK X6qg== 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=KC6lzulLNOZwdcqbQdyOC5RxU6ebFqK4gczLk4LkF+M=; b=bulIw8zTADjqJtFV+CAhO1r1r93pDFx1NuiqdaujYDyDrJ8/0qtkCrcbJsHa0Hv7Bj W1+0sTi2KTBiV3UdUnACGRsKvS4HhsgsSjI59TRhOjyf87fJcxJfkmf4tQEl/a3NkgLG 9E64I2mN4zI7rZ9EyOodJ6At9XVnBiJLy3SquBKD/zkwSnsBwVFVQ4aXlB1ZdH6Q490A DX7kEybIemZJTc8esvZr51ZlxZXcG//EDap9sxgnN9WA52k02Xsmfan7t7AHRu8IshUP uxUzJRAilhb2HzVmUlschiNi7l8DVts12ajJZ3RTYA+t6BxMMN+xQ1ErtH8yk4ygZMof PynQ== X-Gm-Message-State: AOAM531MZwoiZrsde8EMAKnuFTRtF7YpgK1gH13QVWoPGTdd287lZcmv QLiyzyp9DAhELJ8cWNTBbrjdyZlSgsQZBrfJ1P3JZsumHz+XIA== X-Google-Smtp-Source: ABdhPJwWjXNzn/RvYur0ZhEZEew9/2FDciUsUcqVEnA4qc3oTWhBawKRbu5SZz89Z/aEuqnCDSNGJpaXbtOEDAfAa8E= X-Received: by 2002:ac2:443c:: with SMTP id w28mr2013267lfl.79.1607630742373; Thu, 10 Dec 2020 12:05:42 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> In-Reply-To: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> From: Dick Hardt Date: Thu, 10 Dec 2020 12:05:06 -0800 Message-ID: To: Justin Richer Cc: txauth gnap Content-Type: multipart/alternative; boundary="00000000000054519e05b621b3a7" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 10 Dec 2020 20:06:00 -0000 --00000000000054519e05b621b3a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -1 per all the reasons I laid out in https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ =E1=90=A7 On Thu, Dec 10, 2020 at 7:52 AM Justin Richer wrote: > The editors and chairs would like to confirm consensus on a current pull > request: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 > > This pull request simplifies the continuation response and request by > making the access token mandatory, and it clarifies the responsibilities = of > the AS in enforcing the security of the continuation request. Several WG > members expressed specific support for keeping the access token to enable > specific use cases, and there was general support for simplifying the > process from what it currently is in the draft. The editors believe the > pull request represents a solution that meets these goals. > > This call is open until Monday December 14. At that point, the PR will be > merged unless the chairs determine there is not rough consensus for its > inclusion. > > Thank you, > > - Justin, Aaron, and Fabien > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000054519e05b621b3a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-1 per all the reasons I laid out in=C2=A0https= ://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/
3D""=E1=90=A7

On Thu, Dec 10, 2020 at 7:52 AM Justin Richer= <jricher@mit.edu> wrote:
<= /div>
The editors and chairs would like to confirm consensu= s on a current pull request:


This pull request simplifies the continuation response and request by mak= ing the access token mandatory, and it clarifies the responsibilities of th= e AS in enforcing the security of the continuation request. Several WG memb= ers expressed specific support for keeping the access token to enable speci= fic use cases, and there was general support for simplifying the process fr= om what it currently is in the draft. The editors believe the pull request = represents a solution that meets these goals.

This= call is open until Monday December 14. At that point, the PR will be merge= d unless the chairs determine there is not rough consensus for its inclusio= n.

Thank you,

=C2=A0- Jus= tin, Aaron, and Fabien
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000054519e05b621b3a7-- From nobody Fri Dec 11 02:24:25 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145343A0962 for ; Fri, 11 Dec 2020 02:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRKfn2fEZoAu for ; Fri, 11 Dec 2020 02:24:22 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2213A091B for ; Fri, 11 Dec 2020 02:24:19 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id c18so8293797iln.10 for ; Fri, 11 Dec 2020 02:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SxglcoKpjY6t6MDn4++3aP7ghHa53s+grgX6peRwY74=; b=rHkfFTde7xkkDB6etrNo/1Ya/qAzPKT1AydIju4VvU1lwOyVoWROzZlTm2WmENR2Ip rWRv4MacURbsCvzt1coCGID8NbEtHAvnvM6ygbqjPACwaDn2kYN3//c2gheaO/YMj5fY DqtoNX/MN04eGBHAz5QrCb64eCGwAf3eqDZNQ= 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=SxglcoKpjY6t6MDn4++3aP7ghHa53s+grgX6peRwY74=; b=Ua6bMzT+YEUsVSzEKUT/A40K4MdgrwjkHNCoeUzGhWgwBNIjh9TvghCs5Gw4rsJKG5 Rusux6fuWOWzs7gsmfUrPWaA4p153X3+1BXtBSsRanzY4JFxXEW92MYe5wk6Mcs8Adex xfE9GOsuQk6aCTiE5yFBsHgj029lGW3Shlj7ez2+JLFJprSP1xXpO/cBPwALFeoauAwZ KeRRW/vj14jxZnnrM9vRc3U6fkukmsZfwvkMyatmayL57MaFSVU2Vunl647rWTXWvbv7 Ri56e/KY+uFgkr58EwBCFLH95fij4WtI7dSknxcAtgbTO8i7bcf3f/l1g233LA7ZN8C3 8npQ== X-Gm-Message-State: AOAM532c5k9tQyUowyAq78xq79WpnZitHt2dMb9BD5/TkCkCErvmnpzA KUdQ6gSuFHNYMT+L3W0BiCbQ8/UNmT5hzStl9Uf4 X-Google-Smtp-Source: ABdhPJznbrUfl6XGiabX5tDXU4lrgRKoFxzscnWoBhHAI21oOQR1k/PFTdf/DPV0ZGGB6i4c4kQXTgf6KcehTQVCJZI= X-Received: by 2002:a92:358e:: with SMTP id c14mr14454978ilf.69.1607682258259; Fri, 11 Dec 2020 02:24:18 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> In-Reply-To: From: Warren Parad Date: Fri, 11 Dec 2020 11:24:07 +0100 Message-ID: To: Dick Hardt Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000ea669705b62db1a6" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 10:24:24 -0000 --000000000000ea669705b62db1a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For the part I agree with Dick, but I also dislike the separation of the "access token" into its own field. If I understand *continue* correctly, the *access_token *would only ever be used with the *continue *uri, in which case, having the token in the url is much better than having a separate parameter which has to be merged with the continue request to auth it. In my opinion there is no reason to break HATEOAS here, this is one of the few places where the capability URL makes sense, and given its limited use and accessibility the concerns are alleviated. Additionally moving the token back into the uri, avoids the whole problem of naming and how to treat this token. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt wrote: > -1 per all the reasons I laid out in > https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ > =E1=90=A7 > > On Thu, Dec 10, 2020 at 7:52 AM Justin Richer wrote: > >> The editors and chairs would like to confirm consensus on a current pull >> request: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >> >> This pull request simplifies the continuation response and request by >> making the access token mandatory, and it clarifies the responsibilities= of >> the AS in enforcing the security of the continuation request. Several WG >> members expressed specific support for keeping the access token to enabl= e >> specific use cases, and there was general support for simplifying the >> process from what it currently is in the draft. The editors believe the >> pull request represents a solution that meets these goals. >> >> This call is open until Monday December 14. At that point, the PR will b= e >> merged unless the chairs determine there is not rough consensus for its >> inclusion. >> >> Thank you, >> >> - Justin, Aaron, and 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 > --000000000000ea669705b62db1a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the part I agree with Dick, but I also dislike the sep= aration of the "access token" into its own field. If I understand= =C2=A0continue=C2=A0correctly, the access_token would only ev= er be used with the continue uri, in which case, having the token in= the url is much better than having a separate parameter which has to be me= rged with the continue request to auth it. In my opinion there is no reason= to break HATEOAS here, this is one of the few places where the capability = URL makes sense, and given its limited use and accessibility the concerns a= re alleviated. Additionally moving the token back into the uri, avoids the = whole problem of naming and how to treat this token.

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

On Thu, = Dec 10, 2020 at 9:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
3D""=E1=90=A7
On= Thu, Dec 10, 2020 at 7:52 AM Justin Richer <jricher@mit.edu> wrote:
The editors and chairs would = like to confirm consensus on a current pull request:


This pull request simplifies the continuation res= ponse and request by making the access token mandatory, and it clarifies th= e responsibilities of the AS in enforcing the security of the continuation = request. Several WG members expressed specific support for keeping the acce= ss token to enable specific use cases, and there was general support for si= mplifying the process from what it currently is in the draft. The editors b= elieve the pull request represents a solution that meets these goals.
=

This call is open until Monday December 14. At that poi= nt, the PR will be merged unless the chairs determine there is not rough co= nsensus for its inclusion.

Thank you,
=C2=A0- Justin, Aaron, and 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
--000000000000ea669705b62db1a6-- From nobody Fri Dec 11 03:04:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D163A0A26 for ; Fri, 11 Dec 2020 03:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0MKf25j5RY7 for ; Fri, 11 Dec 2020 03:04:17 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D7783A0A2C for ; Fri, 11 Dec 2020 03:04:17 -0800 (PST) Received: from [192.168.1.11] ([90.91.135.71]) by mwinf5d26 with ME id 2z4C2400F1Ybo4i03z4CTC; Fri, 11 Dec 2020 12:04:13 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 11 Dec 2020 12:04:13 +0100 X-ME-IP: 90.91.135.71 To: Fabien Imbault Cc: GNAP Mailing List References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> From: Denis Message-ID: <21cf7c30-c42a-f29c-a407-7badde5c0151@free.fr> Date: Fri, 11 Dec 2020 12:04:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1276A06051D1816DA3C09C1B" Content-Language: en-GB Archived-At: Subject: [GNAP] RS-Token Introspection or RC-Token Introspection 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, 11 Dec 2020 11:04:20 -0000 This is a multi-part message in MIME format. --------------1276A06051D1816DA3C09C1B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, This is a response only to the point 7 from the "Quick review of draft-ietf-gnap-core-protocol-00". The full original text with your comments is copied after my reply. In order to allow the RC to understand the content of an opaque token, you are proposing to support a Token Introspection query from the RC to the AS. This does not solve the concerns of a RC that wants to make sure that the access token does not contain claims that have not been requested. Let us illustrate the case by using an example: The RC asks to the AS to deliver an access token that contains an identifier only unique to the RS. In reality, the AS delivers an access token that does contain an identifier only unique to the RS but in addition a globally unique identifier. Since the access token is supposed to be opaque to the RC, the RC calls the AS to perform a Token Introspection operation. In its response, the AS presents an identifier that is indeed only unique to the RS but the AS voluntarily *omits *to present the globally unique identifier to the RC. In the same way, if Token Introspection is supported by a RS, that does not provide confidence to the end-user or to the RC. Let us illustrate the case by using another example: The AS delivers to the RC an access token that only contains an identifier unique to the RS. Since the access token is supposed to be opaque to the RS, the RS calls the AS to perform a Token Introspection operation. In its response, the AS presents an identifier that is indeed only unique to the RS but the AS voluntarily *adds *a globally unique identifier. _Conclusion_: In both cases, a globally unique identifier will be used by the RS without the RC or the end-user knowing it.                       Opaque tokens are in contradiction with the end-user's privacy. For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered to be opaque to RCs, nor to RSs, and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection. Denis >> 7.The content and the format of access tokens shall not >> be considered to be opaque to the RC so that the RC can >> inspect it. >>     This is a matter of confidence to make sure for the >> RC (and for the user) that no "extra" information has >> been included by the AS into the access token. >> >> [FI] This might go a bit further than the GNAP's mandate >> (especially if it becomes a mandatory requirement). But supposing >> we support non-opaque tokens, >> does it preclude supporting opaque tokens? It's just a different >> trust model, which makes sense if people agree with your premises >> (previous items), >> but that are less relevant if people still consider the AS as the >> central piece. Also one great thing with opaque tokens is that it >> makes the system easier to upgrade >> (you don't really care about what a token is). > > [Denis] Privacy is not more relevant for an AS-centric model than > for a RS-centric model. In particular, a RC should be able to > verify which kind of end-user identifier claim > has been incorporated into the access token by the AS, in > particular whether it is globally unique, unique to the AS only, > unique to the RS only or ephemeral (valid for > that RS during a session with the AS). > > [FI2] ok, see discussion on whether tokens should be opaque or not. > > I suppose that the use of structured access tokens should be > recommended. This means,in particular, that from the very > beginning, we should incorporate a version number > inside each access token. > > >> One alternative way would be to allow RS call to AS for >> verification (including revocation status) and include a checksum. > > [Denis]  The RC, i.e. not the RS, should be able to perform such > verification before presenting the access token to the RS. So this > alternative way would not work. > > [FI2] then there could be a similar API for the client (cf discussion > on similarities between introspection/management APIs). > --------------1276A06051D1816DA3C09C1B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Fabien,

This is a response only to the point 7 from the "Quick review of draft-ietf-gnap-core-protocol-00".
The full original text with your comments is copied after my reply.

In order to allow the RC to understand the content of an opaque token, you are proposing to support a Token Introspection query from the RC to the AS.
This does not solve the concerns of a RC that wants to make sure that the access token does not contain claims that have not been requested.

Let us illustrate the case by using an example:

The RC asks to the AS to deliver an access token that contains an identifier only unique to the RS.
In reality, the AS delivers an access token that does contain an identifier only unique to the RS
but in addition a globally unique identifier. Since the access token is supposed to be opaque to the RC,
the RC calls the AS to perform a Token Introspection operation. In its response, the AS presents an identifier
that is indeed only unique to the RS but the AS voluntarily omits to present the globally unique identifier to the RC.

In the same way, if Token Introspection is supported by a RS, that does not provide confidence to the end-user or to the RC.

Let us illustrate the case by using another example:

The AS delivers to the RC an access token that only contains an identifier unique to the RS. Since the access token
is supposed to be opaque to the RS, the RS calls the AS to perform a Token Introspection operation. In its response,
the AS presents an identifier that is indeed only unique to the RS but the AS voluntarily adds a globally unique identifier.

Conclusion: In both cases, a globally unique identifier will be used by the RS without the RC or the end-user knowing it.
                      Opaque tokens are in contradiction with the end-user's privacy.

For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
to be opaque to RCs, nor to RSs, and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

Denis


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
    This is a matter of confidence to make sure for the RC (and for the user) that no "extra" information has been included by the AS into the access token.

[FI] This might go a bit further than the GNAP's mandate (especially if it becomes a mandatory requirement). But supposing we support non-opaque tokens,
does it preclude supporting opaque tokens? It's just a different trust model, which makes sense if people agree with your premises (previous items),
but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade
(you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for
that RS during a session with the AS).

[FI2] ok, see discussion on whether tokens should be opaque or not.

I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number
inside each access token.


One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum.

[Denis]  The RC, i.e. not the RS, should be able to perform such verification before presenting the access token to the RS. So this alternative way would not work.

[FI2] then there could be a similar API for the client (cf discussion on similarities between introspection/management APIs).


--------------1276A06051D1816DA3C09C1B-- From nobody Fri Dec 11 03:08:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04693A0A2D for ; Fri, 11 Dec 2020 03:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxS4jNg_f-gm for ; Fri, 11 Dec 2020 03:08:12 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F4B3A0A29 for ; Fri, 11 Dec 2020 03:08:11 -0800 (PST) Received: from [192.168.1.11] ([90.91.135.71]) by mwinf5d26 with ME id 2z872400H1Ybo4i03z87yP; Fri, 11 Dec 2020 12:08:07 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 11 Dec 2020 12:08:07 +0100 X-ME-IP: 90.91.135.71 To: "fabien.imbault@gmail.com" References: From: Denis Cc: txauth@ietf.org Message-ID: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> Date: Fri, 11 Dec 2020 12:08:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D08B3E18CA40BCA0A626CFB3" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 11 Dec 2020 11:08:15 -0000 This is a multi-part message in MIME format. --------------D08B3E18CA40BCA0A626CFB3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is a global response to the definitions proposal. Terminology I propose to adopt the way ISO defines how to write the definitions. It is a */single sentence/* that may be substituted to the wording being defined in the context of a sentence that uses that definition. Since this single sentence can be substituted to the wording, there is not point at the end of that sentence. The sentence does not have a "a" or "the" in front of it. If more information is useful to understand the wording, it is placed in one or more notes afterwards. Note: The ISO rules for drafting definitions are in the ISO/IEC Directives, Part 2 (edition 2018): 16.5.6    Definitions The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article (“the”, “a”) nor end with a full stop. A definition shall not take the form of, or contain, a requirement. Only one definition per terminological entry is allowed. If a term is used to define more than one concept, a separate terminological entry shall be created for each concept and the domain shall be included in angle brackets before the definition. Circular definitions, which repeat the term being defined, are not allowed. Comments are inserted between the lines. > Hello everyone, > > As an editor : a quick reminder that terminology issues will be > discussed in the coming weeks, and we're expecting your inputs right > now (according to the process previously sent on the mailing list). > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 > > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > > > The rest of this message is a proposal written in my own name, and > doesn't involve discussions with the editors/chairs who might have > different opinions. > > > *Authorization Server (AS)* > > Manages the granting of privileges to a third-party client instance. > If the RO consents to at least a part of what is requested, the AS > issues an access token to the client. > > /My questions: / > > /- was else do we issue? (e.g. id claims, payment info, etc.) We could > have more than access tokens, but “directed information” is not clear. > I removed that for now./ > > /- there might potentially be several AS, currently we don’t reflect > that anywhere. If would leave that as an open item, depending on what > we end up doing in the spec/ > I am not in favour of this definition: A RO as defined later: "authorizes the request to access a protected resource from the RS to the client". This does not mean in any way that a RO has necessarily a direct relationship with one or more ASs. Using the ISO style for definitions, I propose: Authorization Server (AS): server that grants rights and/or attributes to a particular end-user and that provides them to a client in the form of an access token Since this definition is using the words "rights" and "attributes", these two terms need to be defined as well. right: ability for an end-user to perform a given operation on an object under the control of a RS attribute: property related to an end-user Some explanations: a "right" is able to support a capability scheme. An "attribute" is able to support an ACL scheme. These two schemes are able to support "discretionary access control" where the end-user has a "need-to-know". However, some attributes are also able to support what  was called in the past "mandatory access control"; for example, if the end-user is cleared to "top-secret / marketing strategy". > *Interact Server (IS)*- this is a new proposed term > > Manages the front-end interaction with the RO, in order to gather its > consent. Depending on the deployment model and the privacy requirements, > the IS may be a component of the AS, or may be distinct and managed by > another party. > > Example : an IS usually involves a web interface accessed by RO > through a web browser. > > Note : an IS is not always required, especially if the access is > granted through automated policies. > Using the ISO style for definitions, I propose: Interact_ion_ Server (IS) component from the AS or server interfacing with an AS that manages the interactions with a RO, in order to gather its authorization Note : since the RO is an optional component, the IS is also an optional component. > *Client* > > > Requests privileges from the AS, and uses access tokens at the > RS. This specification differentiates between a specific > instance (the client instance, identified by its unique public key) > and the software running the instance (the client software). . > For some kinds of client software, there could be many instances > of a single piece of client software. > The AS determines which policies apply to a given client > instance, including what it can request and on whose behalf. > Some comments: The above text is stating: "(the client instance, identified by its unique public key)". A client instance may use a public key, but that key is not necessarily unique, in particular when there are multiple ASs. > Example : a client can be a mobile application or a web application > (the client software) that requires authorizations from the RO to > retrieve content from various protected APIs. The client instance may > for instance refer to a specific version of that client software. > > /See on-going discussion : > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 > (client > instance). / > Using the ISO style for definitions, I propose: Client: application used by an end-user to interact with an AS or a RS Note: a client can be a mobile application or a web application. > *Resource Server (RS)* > > Accepts valid access tokens from the client issued by the AS and > serves protected resources on behalf of the RO. There could be > multiple RSs protected by the AS that the client may call. > > Example : a RS is often composed of protected APIs that can be > consumed by authorized client software. > One comment: a RO is not necessarily involved. Using the ISO style for definitions, I propose: Resource Server (RS): server that accepts valid access tokens from clients issued by one or more ASs which are used to grant or deny some requested operations Note: a RS is often composed of protected APIs that can be consumed by clients. > *Resource Owner (RO)* > > Authorizes the request to access a protected resource from the RS to > the client. The RO may decide to remove its consent at any time. > > Note : the RO may be a physical person or may represent an organization. > Two comments: In order to avoid confusion with the end-user consent, the word " authorization" is being used instead of "consent". It should be said that the RO is an optional component.Using the ISO style for definitions, I propose: Resource Owner (RO): physical person acting on its own or representing an organization that authorizes to clients operations on protected resources from a RS Note: The RO is an optional component that may interact either with one RS or with one or more ASs ,e.g. using an IS. > > *End-user* – this was previously Requesting Party RQ > > A physical person that operates and interacts with the client software. > > Note : the end-user may or may not be the same entity as the RO. > The Note is slightly incorrect. the /physical person/may or may not be the same entity as the RO. Using the ISO style for definitions, I propose: End-user :  physical person that operates and interacts with the client software Note : that physical person may or may not be the same entity as the RO. > *Access Token* > > A set of privileges delegated to the client instance for a specific > end-user. An access token is created by the AS, consumed and verified > by the RS, and issued to and carried by the client's end-user on > behalf of the RO. The contents and format of the access token are > opaque to the client. > > Example : JWT is a commonly used format. > > Note 1 : an access token generally has a limited duration, after which > it may be refreshed at a regular interval. > > Note 2 : an access token may be revoked at any time by the RO. > > Note 3 : an access token may act as a capability or require an > additional authentication by binding to a key > A fundamental point: the third sentence from the definition states: "The contents and format of the access token are opaque to the client". See my other email sent today about "RS-Token Introspection or RC-Token Introspection" where I conclude:       For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered       to be opaque to RCs nor to RSs and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection. The example and the other Notes above should be removed. If needed they should be placed in the main body of the document. Using the ISO style for definitions, I propose: Access Token: digitally signed data issued by an Authorization Server (AS) and consumed by a Resource Server (RS)                          that contains rights and/or attributes granted to a particular end-user > *Grant* > > The process by which the client requests and is given delegated access > to the RS by the AS through the authority of the RO. > Using the ISO style for definitions, I propose: Grant: permission given to end-user to use a subset of his rights and/or his attributes at a specific time and for a specific duration > *Key* > > A public cryptographic binding a request to the holder of a private > key. Access tokens and client instances can be associated with > specific keys at a point in time. > > Note : a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > "key" is a general term that is well understood and that does not need to be defined. The "definitions" section is not intended to explain what can be done with the term that is being defined. Until the word "key" is qualified using one or more other terms, this definition should be removed. > *Resource* > > A protected API served by the RS and accessed by the client if and > only if access has been granted. Access to this resource is delegated > by the RO as part of the grant process. > The second sentence of the definition is not in accordance with the ISO style or definitions and furthermore this second sentence should be removed since a RO is an optional element. Using the ISO style for definitions, I propose: Resource: protected API served by a RS and accessed by a client, if and only if access is granted by an access token > > *Subject Information* > > Information about a subject (usually a RO) that is returned directly > to the client from the AS. > > Note : this information needs to be unique. > This definition exhibits several problems: (1) The term "subject" is not defined. (2) The information that is returned is for an end-user, i.e. not for "(usually a RO)". (3) The Note states : "this information needs to be unique". Does it mean unique for the AS ? globally unique ? This definition should be revisited. Denis > > /My questions : / > > /- probably we’d need to define subject/ > > /Subject : > https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry > / > > /- might be useful to clarify the relationship to what identity > providers do / > > > > Cheers > Fabien > > > > --------------D08B3E18CA40BCA0A626CFB3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This is a global response to the definitions proposal.

Terminology

I propose to adopt the way ISO defines how to write the definitions.

It is a single sentence that may be substituted to the wording being defined in the context of a sentence that uses that definition.
Since this single sentence can be substituted to the wording, there is not point at the end of that sentence. The sentence does not
have a "a" or "the" in front of it.

If more information is useful to understand the wording, it is placed in one or more notes afterwards.

Note: The ISO rules for drafting definitions are in the ISO/IEC Directives, Part 2 (edition 2018):
16.5.6    Definitions
The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article (“the”, “a”) nor end with a full stop.
A definition shall not take the form of, or contain, a requirement.

Only one definition per terminological entry is allowed. If a term is used to define more than one concept, a separate terminological entry shall be created
for each concept and the domain shall be included in angle brackets before the definition.

Circular definitions, which repeat the term being defined, are not allowed.
Comments are inserted between the lines.

Hello everyone, 

As an editor : a quick reminder that terminology issues will be discussed in the coming weeks, and we're expecting your inputs right now (according to the process previously sent on the mailing list).

The rest of this message is a proposal written in my own name, and doesn't involve discussions with the editors/chairs who might have different opinions. 

Authorization Server (AS)

Manages the granting of privileges to a third-party client instance. If the RO consents to at least a part of what is requested, the AS issues an access token to the client.

My questions:

- was else do we issue? (e.g. id claims, payment info, etc.) We could have more than access tokens, but “directed information” is not clear. I removed that for now.

- there might potentially be several AS, currently we don’t reflect that anywhere. If would leave that as an open item, depending on what we end up doing in the spec

I am not in favour of this definition: A RO as defined later: "authorizes the request to access a protected resource from the RS to the client".
This does not mean in any way that a RO has necessarily a direct relationship with one or more ASs.

Using the ISO style for definitions, I propose:

Authorization Server (AS): server that grants rights and/or attributes to a particular end-user and that provides them to a client in the form of an access token

Since this definition is using the words "rights" and "attributes", these two terms need to be defined as well.

right: ability for an end-user to perform a given operation on an object under the control of a RS

attribute: property related to an end-user


Some explanations: a "right" is able to support a capability scheme. An "attribute" is able to support an ACL scheme.

These two schemes are able to support "discretionary access control" where the end-user has a "need-to-know".

However, some attributes are also able to support what  was called in the past "mandatory access control"; for example,

if the end-user is cleared to "top-secret / marketing strategy".


Interact Server (IS) - this is a new proposed term

Manages the front-end interaction with the RO, in order to gather its consent. Depending on the deployment model and the privacy requirements,
the IS may be a component of the AS, or may be distinct and managed by another party.

Example : an IS usually involves a web interface accessed by RO through a web browser.

Note : an IS is not always required, especially if the access is granted through automated policies.

Using the ISO style for definitions, I propose:


Interaction Server (IS)

component from the AS or server interfacing with an AS that manages the interactions with a RO, in order to gather its authorization

Note : since the RO is an optional component, the IS is also an optional component.


Client

Requests privileges from the AS, and uses access tokens at the RS. This specification differentiates between a specific instance (the client instance, identified by its unique public key)
and the software running the instance (the client software). . For some kinds of client software, there could be many instances of a single piece of client software.
The AS determines which policies apply to a given client instance, including what it can request and on whose behalf.

Some comments: The above text is stating: "(the client instance, identified by its unique public key)".
A client instance may use a public key, but that key is not necessarily unique, in particular when there are multiple ASs.

Example : a client can be a mobile application or a web application (the client software) that requires authorizations from the RO to retrieve content from various protected APIs. The client instance may for instance refer to a specific version of that client software.

See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance).

Using the ISO style for definitions, I propose:

Client: application used by an end-user to interact with an AS or a RS

Note: a client can be a mobile application or a web application.


Resource Server (RS)

Accepts valid access tokens from the client issued by the AS and serves protected resources on behalf of the RO. There could be multiple RSs protected by the AS that the client may call.

Example : a RS is often composed of protected APIs that can be consumed by authorized client software. 

One comment: a RO is not necessarily involved.

Using the ISO style for definitions, I propose:

Resource Server (RS): server that accepts valid access tokens from clients issued by one or more ASs which are used to grant or deny some requested operations

Note: a RS is often composed of protected APIs that can be consumed by clients.


Resource Owner (RO)

Authorizes the request to access a protected resource from the RS to the client. The RO may decide to remove its consent at any time.

Note : the RO may be a physical person or may represent an organization.


Two comments: In order to avoid confusion with the end-user consent, the word " authorization" is being used instead of "consent".

It should be said that the RO is an optional component. Using the ISO style for definitions, I propose:

Resource Owner (RO): physical person acting on its own or representing an organization that authorizes to clients operations on protected resources from a RS

Note: The RO is an optional component that may interact either with one RS or with one or more ASs ,e.g. using an IS.

End-user – this was previously Requesting Party RQ

A physical person that operates and interacts with the client software.

Note : the end-user may or may not be the same entity as the RO.

The Note is slightly incorrect. the physical person may or may not be the same entity as the RO.

Using the ISO style for definitions, I propose:

End-user :  physical person that operates and interacts with the client software

Note : that physical person may or may not be the same entity as the RO.


Access Token

A set of privileges delegated to the client instance for a specific end-user. An access token is created by the AS, consumed and verified by the RS, and issued to and carried by the client's end-user on behalf of the RO. The contents and format of the access token are opaque to the client.

Example : JWT is a commonly used format.

Note 1 : an access token generally has a limited duration, after which it may be refreshed at a regular interval.

Note 2 : an access token may be revoked at any time by the RO.

Note 3 : an access token may act as a capability or require an additional authentication by binding to a key

A fundamental point: the third sentence from the definition states: "The contents and format of the access token are opaque to the client".

See my other email sent today about "RS-Token Introspection or RC-Token Introspection" where I conclude:

      For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
      to be opaque to RCs nor to RSs and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

The example and the other Notes above should be removed. If needed they should be placed in the main body of the document.

Using the ISO style for definitions, I propose:

Access Token : digitally signed data issued by an Authorization Server (AS) and consumed by a Resource Server (RS)
                         that contains rights and/or attributes granted to a particular end-user


Grant

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

Using the ISO style for definitions, I propose:

Grant: permission given to end-user to use a subset of his rights and/or his attributes at a specific time and for a specific duration

Key

A public cryptographic binding a request to the holder of a private key. Access tokens and client instances can be associated with specific keys at a point in time.

Note : a key can be rotated or revoked by its holder. The protocol supports the update of the key information.

"key" is a general term that is well understood and that does not need to be defined.

The "definitions" section is not intended to explain what can be done with the term that is being defined.
Until the word "key" is qualified using one or more other terms, this definition should be removed.


Resource

A protected API served by the RS and accessed by the client if and only if access has been granted. Access to this resource is delegated by the RO as part of the grant process.

The second sentence of the definition is not in accordance with the ISO style or definitions and furthermore this second sentence should be removed since a RO is an optional element.

 

Using the ISO style for definitions, I propose:

Resource: protected API served by a RS and accessed by a client, if and only if access is granted by an access token

Subject Information

Information about a subject (usually a RO) that is returned directly to the client from the AS.

Note : this information needs to be unique.

 

This definition exhibits several problems:

(1) The term "subject" is not defined.

(2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

(3) The Note states : "this information needs to be unique". Does it mean unique for the AS ? globally unique ?

This definition should be revisited.

Denis


My questions :

- probably we’d need to define subject

Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry

- might be useful to clarify the relationship to what identity providers do 



Cheers
Fabien





--------------D08B3E18CA40BCA0A626CFB3-- From nobody Fri Dec 11 04:31:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B4E3A0B6C for ; Fri, 11 Dec 2020 04:31:06 -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 NnHOHBl7gYB2 for ; Fri, 11 Dec 2020 04:31:02 -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 AE0613A0B61 for ; Fri, 11 Dec 2020 04:31:02 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id z5so9279728iob.11 for ; Fri, 11 Dec 2020 04:31:02 -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=fQDTSzx7QciXobe52BMxlfHTNxWOBwv3+c6R5fa7LLw=; b=IyOd2XzY2aT9P5mHfc5ayFwGAttzO9YBjANg8exQkh5xdPdke2c816h8RrixtsaqFK u7+3F5ijthoKPMWIT1kmphIalnt0IOoou8BZtRr/PD7NMIK5aG0+n0GJSa+Kft8NNLlO R5yxYTZcRVcNQHC1PAPQ3l0M3KEyxbzbswzgnipgaAwVBmTRd6D/SKl1xjaF3Bb+OCXJ BpxwVTE7OdyWMavM6ZlW0f2VeHfxzPipHbADU68D+pjHzyfoHMgeNycWOay3iZimLFJO 9jFbaJlOOUkkuBDFCoedDUoHArueu+dJlP4+YjwdCBRnD9DQhM2qpFiy1RCSNCEQmo4e /+Og== 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=fQDTSzx7QciXobe52BMxlfHTNxWOBwv3+c6R5fa7LLw=; b=qGF1c1y0sNYtGRtX00WBed20XD+bB/VBEsVLDoHj0d1BpM67XY7rM8RcsGn7pnL+pT 4su1aNbkCtxAgaud5otADCAWLzK7jf1PWtsRBNN0zugZX/AmiH0OLy9do5oc0wS3FGVn j962RE8nDL2P9BJcB8sLBv5Uyte1kddlzaLqooLI44sLz0rI6hHeCvOYz2Q6F1mNlLsi jOAz/r2eMeT/c/uJR53FvA+nRm6cx3MPakiJTLITXSExhwTnK4z7alj4/boeJ+yn1y+L G2ofKWv1h/fcYWRrwhMgwiKn9wg80BRgeFLuX9vHLe9FBUnpkal+xDrww09imYtyJftn Tcmw== X-Gm-Message-State: AOAM5309D9J7gM5akAHbVoTRXqaCcTHxNWAipmy3bbe/GxgAtzK6t+QZ uHrvdANeDX2mqu+TV8YRPd66vn6ai6Ypv3/ta88= X-Google-Smtp-Source: ABdhPJxekGI7ZqIERCX1SFPPJN4ESL5d1/Y/acAiQkrRtW75wxQ3SbgNZadDE3ZLI7LIP7RMNXJsZllj1D0vScHAcSY= X-Received: by 2002:a5e:a815:: with SMTP id c21mr14419313ioa.141.1607689861806; Fri, 11 Dec 2020 04:31:01 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> In-Reply-To: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> From: Fabien Imbault Date: Fri, 11 Dec 2020 13:30:50 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000001f3c9f05b62f77ab" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 11 Dec 2020 12:31:06 -0000 --0000000000001f3c9f05b62f77ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, Thanks for your detailed feedback. My comments are embedded into your message. Again those comments are my own, and we'll need to converge to some consensus beyond what I say here. My main open question is really about the RO being optional. Could you explain? Fabien On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: > This is a global response to the definitions proposal. > > Terminology I propose to adopt the way ISO defines how to write the > definitions. It is a *single sentence* that may be substituted to the > wording being defined in the context of a sentence that uses that > definition. > Since this single sentence can be substituted to the wording, there is no= t > point at the end of that sentence. The sentence does not > have a "a" or "the" in front of it. > [FI] In the first version, I was mostly trying to not get too far away from the current text. But yes that's a good idea, it gives a more formal rule, which has been proven to work. > > If more information is useful to understand the wording, it is placed in > one or more notes afterwards. > > Note: The ISO rules for drafting definitions are in the ISO/IEC > Directives, Part 2 (edition 2018): > > 16.5.6 Definitions > > The definition shall be written in such a form that it can replace the > term in its context. It shall not start with an article (=E2=80=9Cthe=E2= =80=9D, =E2=80=9Ca=E2=80=9D) nor > end with a full stop. > A definition shall not take the form of, or contain, a requirement. > > Only one definition per terminological entry is allowed. If a term is use= d > to define more than one concept, a separate terminological entry shall be > created > for each concept and the domain shall be included in angle brackets befor= e > the definition. > > Circular definitions, which repeat the term being defined, are not allowe= d. > > Comments are inserted between the lines. > > Hello everyone, > > As an editor : a quick reminder that terminology issues will be discussed > in the coming weeks, and we're expecting your inputs right now (according > to the process previously sent on the mailing list). > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > > The rest of this message is a proposal written in my own name, and doesn'= t > involve discussions with the editors/chairs who might have different > opinions. > *Authorization Server (AS)* > > Manages the granting of privileges to a third-party client instance. If > the RO consents to at least a part of what is requested, the AS issues an > access token to the client. > > *My questions: * > > *- was else do we issue? (e.g. id claims, payment info, etc.) We could > have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D = is not clear. I > removed that for now.* > > *- there might potentially be several AS, currently we don=E2=80=99t refl= ect that > anywhere. If would leave that as an open item, depending on what we end u= p > doing in the spec* > > I am not in favour of this definition: A RO as defined later: "authorizes > the request to access a protected resource from the RS to the client". > This does not mean in any way that a RO has necessarily a direct > relationship with one or more ASs. [FI] indeed we could remove that > limitation, to have a more general definition > Using the ISO style for definitions, I propose: > > Authorization Server (AS): server that grants rights and/or attributes to > a particular end-user and that provides them to a client in the form of a= n > access token > > Since this definition is using the words "rights" and "attributes", these > two terms need to be defined as well. > > right: ability for an end-user to perform a given operation on an object > under the control of a RS > > attribute: property related to an end-user > > [FI] I like your proposal in general. There might be some discussions on the details. I don't think it makes sense to grant "attributes". > Some explanations: a "right" is able to support a capability scheme. An > "attribute" is able to support an ACL scheme. > > These two schemes are able to support "discretionary access control" wher= e > the end-user has a "need-to-know". > > However, some attributes are also able to support what was called in the > past "mandatory access control"; for example, > > if the end-user is cleared to "top-secret / marketing strategy". > > > *Interact Server (IS)* - this is a new proposed term > > Manages the front-end interaction with the RO, in order to gather its > consent. Depending on the deployment model and the privacy requirements, > the IS may be a component of the AS, or may be distinct and managed by > another party. > > Example : an IS usually involves a web interface accessed by RO through a > web browser. > > Note : an IS is not always required, especially if the access is granted > through automated policies. > > Using the ISO style for definitions, I propose: > > Interact*ion* Server (IS) > > component from the AS or server interfacing with an AS that manages the > interactions with a RO, in order to gather its authorization Note : since > the RO is an optional component, the IS is also an optional component. > > [FI] indeed IS is optional. note for myself when looking at RO : why is RO optional ? > *Client* Requests privileges from the AS, and uses access tokens at the > RS. This specification differentiates between a specific instance (the > client instance, identified by its unique public key) > and the software running the instance (the client software). . For some > kinds of client software, there could be many instances of a single piece > of client software. > The AS determines which policies apply to a given client instance, > including what it can request and on whose behalf. > > Some comments: The above text is stating: "(the client instance, > identified by its unique public key)". > A client instance may use a public key, but that key is not necessarily > unique, in particular when there are multiple ASs. > [FI] yes, although when possible I would still consider a better practice to expose a key to a specific AS and not to the entire set of available ASs. > Example : a client can be a mobile application or a web application (the > client software) that requires authorizations from the RO to retrieve > content from various protected APIs. The client instance may for instance > refer to a specific version of that client software. > > *See on-going discussion : > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 > (client > instance). * > > Using the ISO style for definitions, I propose: > > Client: application used by an end-user to interact with an AS or a RS > > Note: a client can be a mobile application or a web application [FI] for > me those are just examples, because there could me more (ex IoT device) > > [FI] you remove the entire discussion on client instance / client software, is that on purpose because you think it's not useful/right, or is it because of something else? (maybe add your comment of the related issue) > *Resource Server (RS)* > > Accepts valid access tokens from the client issued by the AS and serves > protected resources on behalf of the RO. There could be multiple RSs > protected by the AS that the client may call. > > Example : a RS is often composed of protected APIs that can be consumed b= y > authorized client software. > > One comment: a RO is not necessarily involved. [FI] a bit hard to > imagine, there's some kind of owner. Could you be more explicit? > Using the ISO style for definitions, I propose: > > Resource Server (RS): server that accepts valid access tokens from client= s > issued by one or more ASs which are used to grant or deny some requested > operations > > Note: a RS is often composed of protected APIs that can be consumed by > clients. > > > *Resource Owner (RO)* > > Authorizes the request to access a protected resource from the RS to the > client. The RO may decide to remove its consent at any time. > > Note : the RO may be a physical person or may represent an organization. > > > Two comments: In order to avoid confusion with the end-user consent, the > word " authorization" is being used instead of "consent". [FI] ok > > It should be said that the RO is an optional component. [FI] why? Using > the ISO style for definitions, I propose: > > Resource Owner (RO): physical person acting on its own or representing an > organization that authorizes to clients operations on protected resources > from a RS > > Note: The RO is an optional component that may interact either with one R= S > or with one or more ASs ,e.g. using an IS. > > *End-user* =E2=80=93 this was previously Requesting Party RQ > > A physical person that operates and interacts with the client software. > > Note : the end-user may or may not be the same entity as the RO. > > The Note is slightly incorrect. the *physical person* may or may not be > the same entity as the RO. [FI] I didn't understand your comment > Using the ISO style for definitions, I propose: > > End-user : physical person that operates and interacts with the client > software > > Note : that physical person may or may not be the same entity as the RO. > > > *Access Token* > > A set of privileges delegated to the client instance for a specific > end-user. An access token is created by the AS, consumed and verified by > the RS, and issued to and carried by the client's end-user on behalf of t= he > RO. The contents and format of the access token are opaque to the client. > > Example : JWT is a commonly used format. > > Note 1 : an access token generally has a limited duration, after which it > may be refreshed at a regular interval. > > Note 2 : an access token may be revoked at any time by the RO. > > Note 3 : an access token may act as a capability or require an additional > authentication by binding to a key > > A fundamental point: the third sentence from the definition states: "The > contents and format of the access token are opaque to the client". > [FI] I'll check your other thread dedicated to that issue > See my other email sent today about "RS-Token Introspection or RC-Token > Introspection" where I conclude: > > For end-users caring about their privacy (or for systems willing to > protect the user's privacy), access tokens should not be considered > to be opaque to RCs nor to RSs and ASs should not support Token > Introspection, whether it is RS-Token Introspection or RC-Token > Introspection. > > The example and the other Notes above should be removed. If needed they > should be placed in the main body of the document. > Using the ISO style for definitions, I propose: > > Access Token : digitally signed data issued by an Authorization Server > (AS) and consumed by a Resource Server (RS) > that contains rights and/or attributes granted > to a particular end-user > > > *Grant* > > The process by which the client requests and is given delegated access to > the RS by the AS through the authority of the RO. > > Using the ISO style for definitions, I propose: > > Grant: permission given to end-user to use a subset of his rights and/or > his attributes at a specific time and for a specific duration > > > *Key* > > A public cryptographic binding a request to the holder of a private key. > Access tokens and client instances can be associated with specific keys a= t > a point in time. > > Note : a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > "key" is a general term that is well understood and that does not need to > be defined. [FI] I really wouldn't bet on that. We can reuse an existing > definition but it is a central piece so we need to be explicit > > The "definitions" section is not intended to explain what can be done wit= h > the term that is being defined. [FI] ok we can work on that > Until the word "key" is qualified using one or more other terms, this > definition should be removed. > > *Resource* > > A protected API served by the RS and accessed by the client if and only i= f > access has been granted. Access to this resource is delegated by the RO a= s > part of the grant process. > > The second sentence of the definition is not in accordance with the ISO > style or definitions and furthermore this second sentence should be remov= ed > since a RO is an optional element. > > > Using the ISO style for definitions, I propose: > > Resource: protected API served by a RS and accessed by a client, if and > only if access is granted by an access token > > *Subject Information* > > Information about a subject (usually a RO) that is returned directly to > the client from the AS. > > Note : this information needs to be unique. > > > This definition exhibits several problems: > > (1) The term "subject" is not defined. > > (2) The information that is returned is for an end-user, i.e. not for "(u= sually > a RO)". > > (3) The Note states : "this information needs to be unique". Does it mean > unique for the AS ? globally unique ? > > This definition should be revisited. [FI] I agree (I myself had many > questions here) > > Denis > > > *My questions : * > > *- probably we=E2=80=99d need to define subject* > > *Subject : > https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject= +Dictionary+Entry > * > > *- might be useful to clarify the relationship to what identity providers > do * > > > > Cheers > Fabien > > > > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001f3c9f05b62f77ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

Thanks= for your detailed feedback. My comments are embedded into your message. Ag= ain those comments are my own, and we'll need to converge to some conse= nsus beyond what I say here. My main open question is really about the RO b= eing optional. Could you explain?

Fabien=C2=A0

On Fri, Dec 11, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
This is a global response to the definitions proposal.

Terminology

I p= ropose to adopt the way ISO defines how to write the definitions.

It = is a single sentence that may be substituted to the wording being defined in the context of a sentence that uses that definition.
Since this single sentence can be substituted to the wording, there is not point at the end of that sentence. The sentence does not
have a "a" or "the" in front of it.


= [FI]=C2=A0In the first version, I was mostly= trying to not get too far away from the current text.=C2=A0But=C2=A0yes that= 's a good idea, it gives a more formal rule, which has been proven to w= ork.=C2=A0


If more information is useful to understand the wording, it is placed in one or more notes afterwards.

Note: The ISO rules for drafting definitions = are in the ISO/IEC Directives, Part 2 (edition 2018):
16.5.6=C2=A0=C2=A0=C2=A0 Definitions=
The definition shall be written in s= uch a form that it can replace the term in its context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D= ) nor end with a full stop.
A definition shall not take the form of, or contain, a requirement.

Only one definition per terminological entry i= s allowed. If a term is used to define more than one concept, a separate terminological entry shall be created
for each concept and the domain shall be included in angle brackets before the definition.

Circular definitions, which repeat the term being defined, are not allowed.
Comments are inserted between the lines.

=20
Hello everyone,=C2=A0

As an editor : a quick reminder that terminology=C2=A0issues will be discussed in the coming weeks, and we're expecting your inputs right now (according to the process previously sent on the mailing list).

The rest of this message is a proposal written in my own name, and doesn't involve discussions with the editors/chairs who might have different opinions.=C2=A0

Authorization Server (AS)

= Manages the granting of privileges to a third-party client instance. If the RO consents to at least a part of what is requested, the AS issues an access token to the client.

My questions:

= - was else do we issue? (e.g. id claims, payment info, etc.) We could have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I = removed that for now.

= - there might potentially be several AS, currently we don=E2=80=99t reflect that anywhere. If would leave that as an open item, depending on what we end up doing in the spec

I am not in favour of this definition: A RO as defined later: "authorizes the request to access a protected resource from the RS to the client".
This does not mean in any way that a RO has necessarily a direct relationship with one or more ASs. [FI] indeed we could remove= that limitation, to have a more general definition

Using the ISO style for definitions, I propose:

Authorization Server (AS): server that grants rights and/or attributes to a particular end-user and that provides them to a client in the form of an access token

Since this definition is using the words "rights" and "attributes", these two terms need to be defined as= well.

right: ability for an end-user to perform a given operation on an object under the control of a RS

attribute: property related to an end-user


[FI]= I like your proposal in general. There might be some discussions on the de= tails. I don't think it makes sense to grant "attributes".=C2= =A0=C2=A0=C2=A0

Some explanations: a "right" is able to support a capability scheme. An "attribute" is able to su= pport an ACL scheme.

These two schemes are able to support "discretionary access control" where the end-user has a "need-to-know".

However, some attributes are also able to support what=C2=A0 was called in the past "mandatory access co= ntrol"; for example,

if the end-user is cleared to "top-secret / marketing strategy".


<= font color=3D"#24292e">Interact Server (IS) <= font color=3D"#ff0000">- this is a new proposed term

Manages the front-end interaction with the RO, in order to gather its consent. Depending on the deployment model and the privacy requirements,
the IS may be a component of the AS, or may be distinct and managed by another party.

Example : an IS usually involves a web interface accessed by RO through a web browser.

Note : an IS is not always required, especially if the access is granted through automated policies.

Using the ISO style for definitions, I propose:


Interaction Serv= er (IS)

component from the AS or server interfacing with an AS that manages the interactions with a RO, in order to gather its authorization

Note : since the RO is = an optional component, the IS is also an optional component.

<= /blockquote>

[FI] indeed IS is o= ptional. note for myself when looking at RO : why is RO optional ?=C2=A0=C2= =A0

<= font>Client

Requests privileges from the AS, and uses access tokens at the RS. This specification differentiates between a specific instance (the client instance, identified by its unique public key)
and the software running the instance (the client software). . For some kinds of client software, there could be many instances of a single piece of client software.
The AS determines which policies apply to a given client instance, including what it can request and on whose behalf.

Some comments: The above text is stating: "(the client instance, identified by its unique public key)". A client instance may use a public key, but that key is not necessarily unique, in particular when there are multiple ASs.

<= div>[FI] yes, although when possible I would still = consider a better practice to expose a key to a specific AS and not to the = entire set of available ASs.=C2=A0

= Example : a client can be a mobile application or a web application (the client software) that requires authorizations from the RO to retrieve content from various protected APIs. The client instance may for instance refer to a specific version of that client software.

See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/pull/132 (client instance).

Using the ISO style for definitions, I propose:

Client: application used by an end-user to interact with an AS or a RS

Note: a client can be a mobile application or a web application [FI] for me those are just examples, because the= re could me more (ex IoT device)

[FI] you remove the entire discussion o= n client instance / client software, is that on purpose because you think i= t's not useful/right, or is it because of something else? (maybe add yo= ur comment of the related issue)=C2=A0 =C2=A0

<= font>Resource Server (R= S)

= Accepts valid access tokens from the client issued by the AS and serves protected resources on behalf of the RO. There could be multiple RSs protected by the AS that the client may call.

= Example : a RS is often composed of protected APIs that can be consumed by authorized client software.=C2=A0

One comment: a RO is not necessarily involved. [FI] a bit hard to imagine, there's = some kind of owner. Could you be more explicit?

Using the ISO style for definitions, I propose:

Resource Server (RS): server that accepts valid access tokens from clients issued by one or more ASs which are used to grant or deny some requested operations

Note: a RS is often composed of protected APIs that can be consumed by clients.


Resource Owner (RO)

= Authorizes the request to access a protected resource from the RS to the client. The RO may decide to remove its consent at any time.

= Note : the RO may be a physical person or may represent an organization.


Two comments: In order to avoid confusion with the end-user consent, the word " authorization" is being = used instead of "consent". [FI] ok=C2=A0

It should be said that the RO is an optional component.=C2=A0[FI] why? Using the ISO style for definitions, I propose:

Resource Owner (RO): physical person acting on its own or representing an organization that authorizes to clients operations on protected resources from a RS

Note: The RO is an optional component that may interact either with one RS or with one or more ASs ,e.g. using an IS.

End-user =E2=80=93 this was previously Req= uesting Party RQ

= A physical person that operates and interacts with the client software.

= Note : the end-user may or may not be the same entity as the RO.

The Note is slightly incorrect. the physical person may or ma= y not be the same entity as the RO. [FI] I didn't under= stand your comment

Using the ISO style for definitions, I propose:

End= -user :=C2=A0 physical person that operates and interacts with the client software

Note : that physical = person may or may not be the same entity as the RO.


Access Token

= A set of privileges delegated to the client instance for a specific end-user. An access token is created by the AS, consumed and verified by the RS, and issued to and carried by the client's end-user on behalf of the RO. The contents and format of the access token are opaque to the client.

= Example : JWT is a commonly used format.

= Note 1 : an access token generally has a limited duration, after which it may be refreshed at a regular interval.

= Note 2 : an access token may be revoked at any time by the RO.

Note 3 : an access token may act as a capability or require an additional authentication by binding to a key

A fundamental point: the third sentence from the definition states: "The contents and format of the access token are opaque to the client".

[FI] I'll check your other thread dedicated to that issue=C2=A0

See my other email sent today about "RS-Token Introspection or RC-Token Introspection" where = I conclude:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For end-users caring about th= eir privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 to be opaque to RCs nor to RSs and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

The example and the= other Notes above should be removed. If needed they should be placed in the main body of the document.

Using t= he ISO style for definitions, I propose:

Access Token : digitally signed data issued by an Authorization Server (AS) and consumed by a Resource Server (RS)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 that contains rights and/or attr= ibutes granted to a particular end-user


Grant

= The process by which the client requests and is given delegated access to the RS by the AS through the authority of the RO.<= /font>

Using the ISO style for definitions, I propose:

Grant: permission given to end-user to use a subset of his rights and/or his attributes at a specific time and for a specific duration

Key

= A public cryptographic binding a request to the holder of a private key. Access tokens and client instances can be associated with specific keys at a point in time.

= Note : a key can be rotated or revoked by its holder. The protocol supports the update of the key information.

"key" is a general term that is well understood and that does not need to be defined. [FI] I really= wouldn't bet on that. We can reuse an existing definition but it is a = central piece so we need to be explicit

The "definitions" section is not intended to explain what can be done with the term that is being defined. = [FI] ok we can work on that
Until the word "key" is qualified using one or more other terms, this definition should be removed.


Resource

= A protected API served by the RS and accessed by the client if and only if access has been granted. Access to this resource is delegated by the RO as part of the grant process.=

The second sentence of the definition is not in accordance with the ISO style or definitions and furthermore this second sentence should be removed since a RO is an optional element.

=C2=A0

Using the ISO style for definitions, I propose:

Res= ource: protected API served by a RS and accessed by a client, if and only if access is granted by an access token

Subject Information

= Information about a subject (usually a RO) that is returned directly to the client from the AS.

= Note : this information needs to be unique.

=C2=A0

This definition exhibi= ts several problems:

(1) The term "subject" is not defined.

(2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

(3) The Note states : "this information needs to be unique". Does it mean unique for the AS ? globally unique= ?

This definition should be revisited. = [FI] I agree (I myself had many questions here)

Denis


My questions :

- probably we=E2=80=99d need to define subject

Subject : https://open-measure.atlassian.net/wiki/sp= aces/DIC/pages/67600697/Subject+Dictionary+Entry

- might be useful to clarify the relationship to what identity providers do=C2=A0



Cheers
Fabien





--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000001f3c9f05b62f77ab-- From nobody Fri Dec 11 05:48:21 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5133E3A0C17 for ; Fri, 11 Dec 2020 05:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37RhAQdumpcW for ; Fri, 11 Dec 2020 05:48:12 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5BF3A0C03 for ; Fri, 11 Dec 2020 05:48:11 -0800 (PST) Received: from [192.168.1.11] ([90.91.135.71]) by mwinf5d89 with ME id 31o7240031Ybo4i031o7bQ; Fri, 11 Dec 2020 14:48:08 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 11 Dec 2020 14:48:08 +0100 X-ME-IP: 90.91.135.71 To: Fabien Imbault Cc: GNAP Mailing List References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> From: Denis Message-ID: <4f0015c5-913d-c81e-82ae-d561c4743ddb@free.fr> Date: Fri, 11 Dec 2020 14:48:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------30D9FDAFB50B375CF302E3A5" Content-Language: en-GB Archived-At: Subject: [GNAP] Open question: Why is a RO optional ? 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, 11 Dec 2020 13:48:19 -0000 This is a multi-part message in MIME format. --------------30D9FDAFB50B375CF302E3A5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, In this email, I only respond to the open question:  Why is a RO optional ? Therefore I changed the name of the thread. I expect a RO to communicate from time to time with a RS to define access control rules for the various operations that are possible on the objects managed by the RS. Once these rules have been defined, that are taken automatically into consideration by the RS until then are changed. This guarantees a high throughput. I don't expect a physical person acting on its own behalf or representing an organization to be present 24 hours a day to authorize individual operations on a resource. However, I see two cases where a RO might be involved (leaving apart the case where the end-user and the RO is the same individual). While most operations are handled automatically following access control rules that have been defined either by a RO or by management operations, some specific operations may need a physical person (i.e. a RO) to approve them. a) the RS is able to call a RO. For a few specific operations that requires a human approval, a RO may be involved, but only during working hours. b) the AS is able to call a RO. While this case would be technically possible, I don't like it for reasons explained hereafter: *    the AS must establish prior relationships with all these ROs and *    the AS will be able to know which operations are performed by each end-user on which object.    In that case, the AS will be able to act as Big Brother. Denis > Hi Denis, > > Thanks for your detailed feedback. My comments are embedded into your > message. Again those comments are my own, and we'll need to converge > to some consensus beyond what I say here. My main Natalya Krasavina > . Could > you explain? > > Fabien > > On Fri, Dec 11, 2020 at 12:08 PM Denis > wrote: > > This is a global response to the definitions proposal. > > > Terminology > > > I propose to adopt the way ISO defines how to write the > definitions. > > > It is a */single sentence/* that may be substituted to the > wording being defined in the context of a sentence that uses > that definition. > Since this single sentence can be substituted to the > wording, there is not point at the end of that sentence. The > sentence does not > have a "a" or "the" in front of it. > > > [FI] In the first version, I was mostly trying to not get too far away > from the current text. But yes that's a good idea, it gives a more > formal rule, which has been proven to work. > > > > If more information is useful to understand the wording, it is > placed in one or more notes afterwards. > > Note: The ISO rules for drafting definitions are in the ISO/IEC > Directives, Part 2 (edition 2018): > > 16.5.6    Definitions > > The definition shall be written in such a form that it can > replace the term in its context. It shall not start with an > article (“the”, “a”) nor end with a full stop. > A definition shall not take the form of, or contain, a > requirement. > > Only one definition per terminological entry is allowed. If a > term is used to define more than one concept, a separate > terminological entry shall be created > for each concept and the domain shall be included in angle > brackets before the definition. > > Circular definitions, which repeat the term being defined, are > not allowed. > > Comments are inserted between the lines. > >> Hello everyone, >> >> As an editor : a quick reminder that terminology issues will be >> discussed in the coming weeks, and we're expecting your inputs >> right now (according to the process previously sent on the >> mailing list). >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> >> >> >> The rest of this message is a proposal written in my own name, >> and doesn't involve discussions with the editors/chairs who might >> have different opinions. >> >> >> *Authorization Server (AS)* >> >> Manages the granting of privileges to a third-party client >> instance. If the RO consents to at least a part of what is >> requested, the AS issues an access token to the client. >> >> /My questions: / >> >> /- was else do we issue? (e.g. id claims, payment info, etc.) We >> could have more than access tokens, but “directed information” is >> not clear. I removed that for now./ >> >> /- there might potentially be several AS, currently we don’t >> reflect that anywhere. If would leave that as an open item, >> depending on what we end up doing in the spec/ >> > I am not in favour of this definition: A RO as defined later: > "authorizes the request to access a protected resource from the RS > to the client". > This does not mean in any way that a RO has necessarily a direct > relationship with one or more ASs. [FI] indeed we could remove > that limitation, to have a more general definition > > > Using the ISO style for definitions, I propose: > > Authorization Server (AS): server that grants rights and/or > attributes to a particular end-user and that provides them to > a client in the form of an access token > > Since this definition is using the words "rights" and > "attributes", these two terms need to be defined as well. > > right: ability for an end-user to perform a given operation on > an object under the control of a RS > > attribute: property related to an end-user > > > [FI] I like your proposal in general. There might be some discussions > on the details. I don't think it makes sense to grant "attributes". > > Some explanations: a "right" is able to support a capability > scheme. An "attribute" is able to support an ACL scheme. > > These two schemes are able to support "discretionary access > control" where the end-user has a "need-to-know". > > However, some attributes are also able to support what  was called > in the past "mandatory access control"; for example, > > if the end-user is cleared to "top-secret / marketing strategy". > > >> *Interact Server (IS)*- this is a new proposed term >> >> Manages the front-end interaction with the RO, in order to gather >> its consent. Depending on the deployment model and the privacy >> requirements, >> the IS may be a component of the AS, or may be distinct and >> managed by another party. >> >> Example : an IS usually involves a web interface accessed by RO >> through a web browser. >> >> Note : an IS is not always required, especially if the access is >> granted through automated policies. >> > Using the ISO style for definitions, I propose: > > > Interact_ion_ Server (IS) > > component from the AS or server interfacing with an AS > that manages the interactions with a RO, in order to > gather its authorization > > > Note : since the RO is an optional component, the IS is > also an optional component. > > > [FI] indeed IS is optional. note for myself when looking at RO : why > is RO optional ? > >> >> *Client* >> >> >> Requests privileges from the AS, and uses access tokens at >> the RS. This specification differentiates between a >> specific instance (the client instance, identified by its >> unique public key) >> and the software running the instance (the client >> software). . For some kinds of client software, there could >> be many instances of a single piece of client software. >> The AS determines which policies apply to a given client >> instance, including what it can request and on whose behalf. >> > > Some comments: The above text is stating: "(the client > instance, identified by its unique public key)". > A client instance may use a public key, but that key is not > necessarily unique, in particular when there are multiple ASs. > > [FI] yes, although when possible I would still consider a better > practice to expose a key to a specific AS and not to the entire set of > available ASs. > >> Example : a client can be a mobile application or a web >> application (the client software) that requires authorizations >> from the RO to retrieve content from various protected APIs. The >> client instance may for instance refer to a specific version of >> that client software. >> >> /See on-going discussion : >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 >> >> (client instance). / >> > > Using the ISO style for definitions, I propose: > > > Client: application used by an end-user to interact with > an AS or a RS > > Note: a client can be a mobile application or a web > application [FI] for me those are just examples, because there > could me more (ex IoT device) > > [FI] you remove the entire discussion on client instance / client > software, is that on purpose because you think it's not useful/right, > or is it because of something else? (maybe add your comment of the > related issue) > >> >> *Resource Server (RS)* >> >> Accepts valid access tokens from the client issued by the AS and >> serves protected resources on behalf of the RO. There could be >> multiple RSs protected by the AS that the client may call. >> >> Example : a RS is often composed of protected APIs that can be >> consumed by authorized client software. >> > One comment: a RO is not necessarily involved. [FI] a bit hard to > imagine, there's some kind of owner. Could you be more explicit? > > > Using the ISO style for definitions, I propose: > > Resource Server (RS): server that accepts valid access tokens > from clients issued by one or more ASs which are used to grant > or deny some requested operations > > Note: a RS is often composed of protected APIs that can be > consumed by clients. > > >> *Resource Owner (RO)* >> >> Authorizes the request to access a protected resource from the RS >> to the client. The RO may decide to remove its consent at any time. >> >> Note : the RO may be a physical person or may represent an >> organization. >> > > Two comments: In order to avoid confusion with the end-user > consent, the word " authorization" is being used instead of > "consent". [FI] ok > > It should be said that the RO is an optional component.[FI] why? > Using the ISO style for definitions, I propose: > > Resource Owner (RO): physical person acting on its own or > representing an organization that authorizes to clients > operations on protected resources from a RS > > Note: The RO is an optional component that may interact either > with one RS or with one or more ASs ,e.g. using an IS. > >> >> *End-user* – this was previously Requesting Party RQ >> >> A physical person that operates and interacts with the client >> software. >> >> Note : the end-user may or may not be the same entity as the RO. >> > The Note is slightly incorrect. the /physical person/may or may > not be the same entity as the RO. [FI] I didn't understand your > comment > > > Using the ISO style for definitions, I propose: > > > End-user :  physical person that operates and interacts > with the client software > > Note : that physical person may or may not be the same entity > as the RO. > > >> *Access Token* >> >> A set of privileges delegated to the client instance for a >> specific end-user. An access token is created by the AS, consumed >> and verified by the RS, and issued to and carried by the client's >> end-user on behalf of the RO. The contents and format of the >> access token are opaque to the client. >> >> Example : JWT is a commonly used format. >> >> Note 1 : an access token generally has a limited duration, after >> which it may be refreshed at a regular interval. >> >> Note 2 : an access token may be revoked at any time by the RO. >> >> Note 3 : an access token may act as a capability or require an >> additional authentication by binding to a key >> > A fundamental point: the third sentence from the definition > states: "The contents and format of the access token are opaque to > the client". > > [FI] I'll check your other thread dedicated to that issue > > See my other email sent today about "RS-Token Introspection or > RC-Token Introspection" where I conclude: > >       For end-users caring about their privacy (or for systems > willing to protect the user's privacy), access tokens should not > be considered >       to be opaque to RCs nor to RSs and ASs should not support > Token Introspection, whether it is RS-Token Introspection or > RC-Token Introspection. > > The example and the other Notes above should be removed. If needed > they should be placed in the main body of the document. > > Using the ISO style for definitions, I propose: > > Access Token: digitally signed data issued by an Authorization > Server (AS) and consumed by a Resource Server (RS) >                          that contains rights and/or > attributes granted to a particular end-user > > >> *Grant* >> >> The process by which the client requests and is given delegated >> access to the RS by the AS through the authority of the RO. >> > > Using the ISO style for definitions, I propose: > > Grant: permission given to end-user to use a subset of his > rights and/or his attributes at a specific time and for a > specific duration > > >> *Key* >> >> A public cryptographic binding a request to the holder of a >> private key. Access tokens and client instances can be associated >> with specific keys at a point in time. >> >> Note : a key can be rotated or revoked by its holder. The >> protocol supports the update of the key information. >> > "key" is a general term that is well understood and that does not > need to be defined. [FI] I really wouldn't bet on that. We can > reuse an existing definition but it is a central piece so we need > to be explicit > > The "definitions" section is not intended to explain what can be > done with the term that is being defined. [FI] ok we can work on that > Until the word "key" is qualified using one or more other terms, > this definition should be removed. > > >> *Resource* >> >> A protected API served by the RS and accessed by the client if >> and only if access has been granted. Access to this resource is >> delegated by the RO as part of the grant process. >> > The second sentence of the definition is not in accordance with > the ISO style or definitions and furthermore this second sentence > should be removed since a RO is an optional element. > > > Using the ISO style for definitions, I propose: > > > Resource: protected API served by a RS and accessed by a > client, if and only if access is granted by an access token > >> >> *Subject Information* >> >> Information about a subject (usually a RO) that is returned >> directly to the client from the AS. >> >> Note : this information needs to be unique. >> > This definition exhibits several problems: > > (1) The term "subject" is not defined. > > (2) The information that is returned is for an end-user, i.e. > not for "(usually a RO)". > > (3) The Note states : "this information needs to be unique". > Does it mean unique for the AS ? globally unique ? > > This definition should be revisited. [FI] I agree (I myself had > many questions here) > > Denis > >> >> /My questions : / >> >> /- probably we’d need to define subject/ >> >> /Subject : >> https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry >> / >> >> /- might be useful to clarify the relationship to what identity >> providers do / >> >> >> >> Cheers >> Fabien >> >> >> >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --------------30D9FDAFB50B375CF302E3A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Fabien,

In this email, I only respond to the open question:  Why is a RO optional ?
Therefore I changed the name of the thread.

I expect a RO to communicate from time to time with a RS to define access control rules for the various operations that are possible on the objects managed by the RS.
Once these rules have been defined, that are taken automatically into consideration by the RS until then are changed. This guarantees a high throughput.

I don't expect a physical person acting on its own behalf or representing an organization to be present 24 hours a day to authorize individual operations on a resource.

However, I see two cases where a RO might be involved (leaving apart the case where the end-user and the RO is the same individual).
While most operations are handled automatically following access control rules that have been defined either by a RO or by management operations,
some specific operations may need a physical person (i.e. a RO) to approve them.

a)  the RS is able to call a RO. For a few specific operations that requires a human approval, a RO may be involved, but only during working hours. 

b) the AS is able to call a RO. While this case would be technically possible, I don't like it for reasons explained hereafter:
  •    the AS must establish prior relationships with all these ROs and
  •    the AS will be able to know which operations are performed by each end-user on which object. 
       In that case, the AS will be able to act as Big Brother.
Denis

Hi Denis, 

Thanks for your detailed feedback. My comments are embedded into your message. Again those comments are my own, and we'll need to converge to some consensus beyond what I say here. My main Natalya Krasavina. Could you explain?

Fabien 

On Fri, Dec 11, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:
This is a global response to the definitions proposal.

Terminology

I propose to adopt the way ISO defines how to write the definitions.

It is a single sentence that may be substituted to the wording being defined in the context of a sentence that uses that definition.
Since this single sentence can be substituted to the wording, there is not point at the end of that sentence. The sentence does not
have a "a" or "the" in front of it.


[FI] In the first version, I was mostly trying to not get too far away from the current text. But yes that's a good idea, it gives a more formal rule, which has been proven to work. 


If more information is useful to understand the wording, it is placed in one or more notes afterwards.

Note: The ISO rules for drafting definitions are in the ISO/IEC Directives, Part 2 (edition 2018):
16.5.6    Definitions
The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article (“the”, “a”) nor end with a full stop.
A definition shall not take the form of, or contain, a requirement.

Only one definition per terminological entry is allowed. If a term is used to define more than one concept, a separate terminological entry shall be created
for each concept and the domain shall be included in angle brackets before the definition.

Circular definitions, which repeat the term being defined, are not allowed.
Comments are inserted between the lines.

Hello everyone, 

As an editor : a quick reminder that terminology issues will be discussed in the coming weeks, and we're expecting your inputs right now (according to the process previously sent on the mailing list).

The rest of this message is a proposal written in my own name, and doesn't involve discussions with the editors/chairs who might have different opinions. 

Authorization Server (AS)

Manages the granting of privileges to a third-party client instance. If the RO consents to at least a part of what is requested, the AS issues an access token to the client.

My questions:

- was else do we issue? (e.g. id claims, payment info, etc.) We could have more than access tokens, but “directed information” is not clear. I removed that for now.

- there might potentially be several AS, currently we don’t reflect that anywhere. If would leave that as an open item, depending on what we end up doing in the spec

I am not in favour of this definition: A RO as defined later: "authorizes the request to access a protected resource from the RS to the client".
This does not mean in any way that a RO has necessarily a direct relationship with one or more ASs. [FI] indeed we could remove that limitation, to have a more general definition

Using the ISO style for definitions, I propose:

Authorization Server (AS): server that grants rights and/or attributes to a particular end-user and that provides them to a client in the form of an access token

Since this definition is using the words "rights" and "attributes", these two terms need to be defined as well.

right: ability for an end-user to perform a given operation on an object under the control of a RS

attribute: property related to an end-user


[FI] I like your proposal in general. There might be some discussions on the details. I don't think it makes sense to grant "attributes".   

Some explanations: a "right" is able to support a capability scheme. An "attribute" is able to support an ACL scheme.

These two schemes are able to support "discretionary access control" where the end-user has a "need-to-know".

However, some attributes are also able to support what  was called in the past "mandatory access control"; for example,

if the end-user is cleared to "top-secret / marketing strategy".


Interact Server (IS) - this is a new proposed term

Manages the front-end interaction with the RO, in order to gather its consent. Depending on the deployment model and the privacy requirements,
the IS may be a component of the AS, or may be distinct and managed by another party.

Example : an IS usually involves a web interface accessed by RO through a web browser.

Note : an IS is not always required, especially if the access is granted through automated policies.

Using the ISO style for definitions, I propose:


Interaction Server (IS)

component from the AS or server interfacing with an AS that manages the interactions with a RO, in order to gather its authorization

Note : since the RO is an optional component, the IS is also an optional component.


[FI] indeed IS is optional. note for myself when looking at RO : why is RO optional ?  

Client

Requests privileges from the AS, and uses access tokens at the RS. This specification differentiates between a specific instance (the client instance, identified by its unique public key)
and the software running the instance (the client software). . For some kinds of client software, there could be many instances of a single piece of client software.
The AS determines which policies apply to a given client instance, including what it can request and on whose behalf.

Some comments: The above text is stating: "(the client instance, identified by its unique public key)".
A client instance may use a public key, but that key is not necessarily unique, in particular when there are multiple ASs.

[FI] yes, although when possible I would still consider a better practice to expose a key to a specific AS and not to the entire set of available ASs. 

Example : a client can be a mobile application or a web application (the client software) that requires authorizations from the RO to retrieve content from various protected APIs. The client instance may for instance refer to a specific version of that client software.

See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance).

Using the ISO style for definitions, I propose:

Client: application used by an end-user to interact with an AS or a RS

Note: a client can be a mobile application or a web application [FI] for me those are just examples, because there could me more (ex IoT device)

[FI] you remove the entire discussion on client instance / client software, is that on purpose because you think it's not useful/right, or is it because of something else? (maybe add your comment of the related issue)   

Resource Server (RS)

Accepts valid access tokens from the client issued by the AS and serves protected resources on behalf of the RO. There could be multiple RSs protected by the AS that the client may call.

Example : a RS is often composed of protected APIs that can be consumed by authorized client software. 

One comment: a RO is not necessarily involved. [FI] a bit hard to imagine, there's some kind of owner. Could you be more explicit?

Using the ISO style for definitions, I propose:

Resource Server (RS): server that accepts valid access tokens from clients issued by one or more ASs which are used to grant or deny some requested operations

Note: a RS is often composed of protected APIs that can be consumed by clients.


Resource Owner (RO)

Authorizes the request to access a protected resource from the RS to the client. The RO may decide to remove its consent at any time.

Note : the RO may be a physical person or may represent an organization.


Two comments: In order to avoid confusion with the end-user consent, the word " authorization" is being used instead of "consent". [FI] ok 

It should be said that the RO is an optional component. [FI] why? Using the ISO style for definitions, I propose:

Resource Owner (RO): physical person acting on its own or representing an organization that authorizes to clients operations on protected resources from a RS

Note: The RO is an optional component that may interact either with one RS or with one or more ASs ,e.g. using an IS.

End-user – this was previously Requesting Party RQ

A physical person that operates and interacts with the client software.

Note : the end-user may or may not be the same entity as the RO.

The Note is slightly incorrect. the physical person may or may not be the same entity as the RO. [FI] I didn't understand your comment

Using the ISO style for definitions, I propose:

End-user :  physical person that operates and interacts with the client software

Note : that physical person may or may not be the same entity as the RO.


Access Token

A set of privileges delegated to the client instance for a specific end-user. An access token is created by the AS, consumed and verified by the RS, and issued to and carried by the client's end-user on behalf of the RO. The contents and format of the access token are opaque to the client.

Example : JWT is a commonly used format.

Note 1 : an access token generally has a limited duration, after which it may be refreshed at a regular interval.

Note 2 : an access token may be revoked at any time by the RO.

Note 3 : an access token may act as a capability or require an additional authentication by binding to a key

A fundamental point: the third sentence from the definition states: "The contents and format of the access token are opaque to the client".

[FI] I'll check your other thread dedicated to that issue 

See my other email sent today about "RS-Token Introspection or RC-Token Introspection" where I conclude:

      For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
      to be opaque to RCs nor to RSs and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

The example and the other Notes above should be removed. If needed they should be placed in the main body of the document.

Using the ISO style for definitions, I propose:

Access Token : digitally signed data issued by an Authorization Server (AS) and consumed by a Resource Server (RS)
                         that contains rights and/or attributes granted to a particular end-user


Grant

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

Using the ISO style for definitions, I propose:

Grant: permission given to end-user to use a subset of his rights and/or his attributes at a specific time and for a specific duration

Key

A public cryptographic binding a request to the holder of a private key. Access tokens and client instances can be associated with specific keys at a point in time.

Note : a key can be rotated or revoked by its holder. The protocol supports the update of the key information.

"key" is a general term that is well understood and that does not need to be defined. [FI] I really wouldn't bet on that. We can reuse an existing definition but it is a central piece so we need to be explicit

The "definitions" section is not intended to explain what can be done with the term that is being defined. [FI] ok we can work on that
Until the word "key" is qualified using one or more other terms, this definition should be removed.


Resource

A protected API served by the RS and accessed by the client if and only if access has been granted. Access to this resource is delegated by the RO as part of the grant process.

The second sentence of the definition is not in accordance with the ISO style or definitions and furthermore this second sentence should be removed since a RO is an optional element.

 

Using the ISO style for definitions, I propose:

Resource: protected API served by a RS and accessed by a client, if and only if access is granted by an access token

Subject Information

Information about a subject (usually a RO) that is returned directly to the client from the AS.

Note : this information needs to be unique.

 

This definition exhibits several problems:

(1) The term "subject" is not defined.

(2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

(3) The Note states : "this information needs to be unique". Does it mean unique for the AS ? globally unique ?

This definition should be revisited. [FI] I agree (I myself had many questions here)

Denis


My questions :

- probably we’d need to define subject

Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry

- might be useful to clarify the relationship to what identity providers do 



Cheers
Fabien





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


--------------30D9FDAFB50B375CF302E3A5-- From nobody Fri Dec 11 06:18:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979633A0C27 for ; Fri, 11 Dec 2020 06:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzMkpzxdyeQt for ; Fri, 11 Dec 2020 06:18:05 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AABA3A0C1B for ; Fri, 11 Dec 2020 06:18:05 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id o8so9640885ioh.0 for ; Fri, 11 Dec 2020 06:18:05 -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=SEHOQc4JfnXGi2wAt8zBgnhz+6EelVOSKEf84G2Q08M=; b=Gd4D1s1T7+nU2Qi4FKETTa9nbeNvKJphCYREY+f2suQSz7DyIu48eZiSw7suieowLf TOyb/eWH3P4ZOEEo8R4PW6ojxVdw4P2haYPW+fqstpf1LXiP2aLjg2L+VkEKgYRrviYW vs+WXsmRgRXJxv+0+Xa+YXVP8YoADNjKQTwtR3Q1gYL+7ijPR/ccD6igSLbrCIsy94o2 oH//MIcHeP+0Yfr387HsyTmLxBRwWB7YGWjEYfpqUhw7JFXyPyxKC0XQTE5NneCdi5xF Cf6+c+5OPDImbteQZKr7WIi4vCOmNyOwLvnle61E0auBlhloYeA00t3SpKPRbyoqOqUv 3CkQ== 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=SEHOQc4JfnXGi2wAt8zBgnhz+6EelVOSKEf84G2Q08M=; b=Vgaxw2NjJBsQqsMN1zexbi/8KrH9RQG5SAlWLeC/Lo6uPq4gbva51Ox+rqnDKgTOui sn+km2l/BMBRLkOsHchyR/PszI4uYdcaDzBuje72dWOv2YhlLAgyN7rJwZRXVlg+9emi cqT+p9DVLM7U4xyG0ULZstEdekavjT/8o4sAZi1nrZwzZsn4GRZnylJgMY9Cazv45O2Z 0ZToeBd2RALHLd5rmoChTFtJrdvI5ajPIVv+hpz8pWLoV1N0oBbXjVLVLSUqD2BWggr5 t0bPTgikiv/ZzkEtytErK7sv45Ia/qrQ0yZFFOEKAAvJ7Do563dgsXqpYp3bRg/N+ROK C7AA== X-Gm-Message-State: AOAM530dHsq8HL3Q3xONkQH2dikHvCzXjeWNiSkmOpX06oOs4g1dnVV9 q0KqfTtAhdN91VjkgV8wWXBTdAuHlKBXry/0aUg= X-Google-Smtp-Source: ABdhPJxhb/Xv4pLpXllSQ9g2Ta8tgZ+68xl5fgYru1POyiXo6Tt8ALEmkYb5SQIXII8Bvm1o9Gof7IER/Flnmv6iNNE= X-Received: by 2002:a5e:a916:: with SMTP id c22mr15328431iod.144.1607696284645; Fri, 11 Dec 2020 06:18:04 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> In-Reply-To: From: Fabien Imbault Date: Fri, 11 Dec 2020 15:17:53 +0100 Message-ID: To: Warren Parad Cc: Dick Hardt , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="000000000000f3fc3305b630f53d" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 14:18:08 -0000 --000000000000f3fc3305b630f53d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I commented previously on Dick's input (in short, I disagree - at least with the cookie comparison). I'm not sure I follow your point here. "access_token" already has its field, the proposal is just reusing it throughout the protocol (see for instance section 3.2.1) as a fairly consistent api. The only difference is the meaning of the "key" boolean parameter (which I would be in favor of renaming to clarify). The proposed alternative comes with issues with seem very hard to get around, at least in a systematic way. Like potential logs of capability URLs that include the token, which opens the doors to vulnerable implementations. Fabien On Fri, Dec 11, 2020 at 11:24 AM Warren Parad wrote: > For the part I agree with Dick, but I also dislike the separation of the > "access token" into its own field. If I understand *continue* correctly, > the *access_token *would only ever be used with the *continue *uri, in > which case, having the token in the url is much better than having a > separate parameter which has to be merged with the continue request to au= th > it. In my opinion there is no reason to break HATEOAS here, this is one o= f > the few places where the capability URL makes sense, and given its limite= d > use and accessibility the concerns are alleviated. Additionally moving th= e > token back into the uri, avoids the whole problem of naming and how to > treat this token. > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt wrote: > >> -1 per all the reasons I laid out in >> https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY= / >> =E1=90=A7 >> >> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer wrote: >> >>> The editors and chairs would like to confirm consensus on a current pul= l >>> request: >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >>> >>> This pull request simplifies the continuation response and request by >>> making the access token mandatory, and it clarifies the responsibilitie= s of >>> the AS in enforcing the security of the continuation request. Several W= G >>> members expressed specific support for keeping the access token to enab= le >>> specific use cases, and there was general support for simplifying the >>> process from what it currently is in the draft. The editors believe the >>> pull request represents a solution that meets these goals. >>> >>> This call is open until Monday December 14. At that point, the PR will >>> be merged unless the chairs determine there is not rough consensus for = its >>> inclusion. >>> >>> Thank you, >>> >>> - Justin, Aaron, and 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 > --000000000000f3fc3305b630f53d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I commented previously on Dic= k's input (in short, I disagree - at least with the=C2=A0cookie compari= son).

I'm not sure I follow your point here. &= quot;access_token" already has its field, the proposal is just reusing= it throughout the protocol (see for instance section 3.2.1) as a fairly co= nsistent api. The only difference is the meaning of the "key" boo= lean parameter (which I would be in favor of renaming to clarify).

The proposed alternative comes with issues with seem very = hard to get around, at least in a systematic way. Like potential logs of ca= pability URLs that include the token, which opens the doors to vulnerable i= mplementations.=C2=A0

Fabien

On Fri, Dec 11, = 2020 at 11:24 AM Warren Parad <wpara= d@rhosys.ch> wrote:
For the part I agree with Dick, but I also disl= ike the separation of the "access token" into its own field. If I= understand=C2=A0continue=C2=A0correctly, the access_token wo= uld only ever be used with the continue uri, in which case, having t= he token in the url is much better than having a separate parameter which h= as to be merged with the continue request to auth it. In my opinion there i= s no reason to break HATEOAS here, this is one of the few places where the = capability URL makes sense, and given its limited use and accessibility the= concerns are alleviated. Additionally moving the token back into the uri, = avoids the whole problem of naming and how to treat this token.

Warren Parad

Founder, CTO

=

Warren Parad

Founder, CTO

Secure your us= er data and complete your authorization architecture. Implement=C2=A0Authress.


On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt <dick.hardt@gmail.com>= ; wrote:
3D""=E1=90=A7

On Thu, Dec 10, 2020 at 7:52 AM J= ustin Richer <jrich= er@mit.edu> wrote:
The editors and chairs would like to confirm consensus on a= current pull request:


This= pull request simplifies the continuation response and request by making th= e access token mandatory, and it clarifies the responsibilities of the AS i= n enforcing the security of the continuation request. Several WG members ex= pressed specific support for keeping the access token to enable specific us= e cases, and there was general support for simplifying the process from wha= t it currently is in the draft. The editors believe the pull request repres= ents a solution that meets these goals.

This call = is open until Monday December 14. At that point, the PR will be merged unle= ss the chairs determine there is not rough consensus for its inclusion.

Thank you,

=C2=A0- Justin, A= aron, and 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
--000000000000f3fc3305b630f53d-- From nobody Fri Dec 11 08:08:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506C13A0CEA for ; Fri, 11 Dec 2020 08:08: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 3gCCYasdB0_9 for ; Fri, 11 Dec 2020 08:08:25 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EF83A0CE9 for ; Fri, 11 Dec 2020 08:08:25 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id t9so9254041ilf.2 for ; Fri, 11 Dec 2020 08:08: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=7Tt6XlHMNLrOWGsRck33pJcgspDKGAp3bl2BNiMUD4A=; b=pw87agwD++2s9i0iPJ4IH30FmqXA4LFPqI6nBA0PiGgQqpyFe3Qa47NXybNigpWSfK CFQfvuq626YRKaXJVH0OJq3BAZ+kaiTXU75KOSjYuq/7ohhZosSt1zjfDaV5tX7+5Lfi FJV6Cem6UzLZZiEVQX4FFCyPYIZTZw4JxcXwrz5LMMCjBKvHPXeRBP+csh52e8JDDSpW /WUFcgbMw0Wk431HL2vgbbuybw+lfl8k8dgImVHQJdyv9A1An0LEOCyA85PmQfST93eQ tf7GB4e03/hIAmWLv9J+qkcH/TfefmURapd6iNjc/o6qmab01RRjgocMOcESJTUVO8NY u5ng== 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=7Tt6XlHMNLrOWGsRck33pJcgspDKGAp3bl2BNiMUD4A=; b=RueiX+vNtg6R3LiHKgtCYDCZqFNfXOmASEfkcTknRjnOw1cJgk98RtHxDo0uTrUygG VA8xFs6rxCuUesajE+SLY/V9fCKT84hbseLrup9GNSIxRywTQg9GMoWbkx/yqYmoHAOq lKfO4mdURmodFhtsWPfZazUxeNxioj3Aw0yjw0fZh64q/5/WqMqRDIluoXkEQc6fQhh7 LJPFQuAkGnAJQC1C8gVStHCkCYwfjJbq1lQUFONpshEFQZN9LLsj4NeQShD5s0itmCIq abguyFHWqarRujxYhh9hIzEdVzDx/7NIpf8oybQZB0DTEig2+D7B7++ZRngv/R1Zt/en uQwA== X-Gm-Message-State: AOAM530vU3wAxn/himpgIxK9peFfo+zn34oVApqlJrHp+VbPPfGbAYPW svBtfUBUJDPJNgUkcHo1TTYXks7zSDa4jKkfXUM= X-Google-Smtp-Source: ABdhPJx75maVdGcpCpn0P8oE4ECcip+obhwNTL5688n7xu/xNsOCwzfdlzd3hzt37ZB2GNrOKKCgmXM6f5J8OFIcE/Y= X-Received: by 2002:a92:d0ca:: with SMTP id y10mr17218968ila.68.1607702904466; Fri, 11 Dec 2020 08:08:24 -0800 (PST) MIME-Version: 1.0 References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> <21cf7c30-c42a-f29c-a407-7badde5c0151@free.fr> In-Reply-To: <21cf7c30-c42a-f29c-a407-7badde5c0151@free.fr> From: Fabien Imbault Date: Fri, 11 Dec 2020 17:08:13 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000086712205b632806c" Archived-At: Subject: Re: [GNAP] RS-Token Introspection or RC-Token Introspection 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, 11 Dec 2020 16:08:27 -0000 --00000000000086712205b632806c Content-Type: text/plain; charset="UTF-8" Hi Denis, Please note that the token introspection is not a new idea, it's already present in OAuth2 world (rfc 7662), and allows the RS to verify the access token. In the current version of GNAP, there is also section 6 that introduces management endpoints, which could potentially be extended in a similar way (currently this is not specified, the management endpoint is here for rotation/revocation). Then the client could require more information on what is included in the opaque token, but of course, this relies on the assumption that the client trusts the AS. There is also the discussion on the "resource" description in the response, that may provide a simpler scheme (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141). But if we assume the AS may be malevolent (which is more likely if the AS becomes a less central point, at least for some implementations), then indeed receiving opaque tokens wouldn't provide all the guarantees, as it may lie on what is really in the token (too many claims for instance). More specifically, while I recon there might be a risk which we'd rather not have, I don't really think an opaque token is really an unmanageable issue with privacy. Suppose someone adds a field in a JWT, most likely you'll be able to detect that. But suppose we go for non opaque tokens, then we'd need a way of describing its format. Which might limit a bit the use cases if we're not careful. I'd be interested to know what others think, since it is diverging quite a bit from the OAuth2 world (not a bad thing in itself but still). Fabien On Fri, Dec 11, 2020 at 12:04 PM Denis wrote: > Hi Fabien, > > This is a response only to the point 7 from the "Quick review of > draft-ietf-gnap-core-protocol-00". > The full original text with your comments is copied after my reply. > > In order to allow the RC to understand the content of an opaque token, you > are proposing to support a Token Introspection query from the RC to the AS. > This does not solve the concerns of a RC that wants to make sure that the > access token does not contain claims that have not been requested. > > Let us illustrate the case by using an example: > > The RC asks to the AS to deliver an access token that contains an > identifier only unique to the RS. > In reality, the AS delivers an access token that does contain an > identifier only unique to the RS > but in addition a globally unique identifier. Since the access token is > supposed to be opaque to the RC, > the RC calls the AS to perform a Token Introspection operation. In its > response, the AS presents an identifier > that is indeed only unique to the RS but the AS voluntarily *omits *to > present the globally unique identifier to the RC. > > In the same way, if Token Introspection is supported by a RS, that does > not provide confidence to the end-user or to the RC. > > Let us illustrate the case by using another example: > > The AS delivers to the RC an access token that only contains an identifier > unique to the RS. Since the access token > is supposed to be opaque to the RS, the RS calls the AS to perform a Token > Introspection operation. In its response, > the AS presents an identifier that is indeed only unique to the RS but the > AS voluntarily *adds *a globally unique identifier. > > *Conclusion*: In both cases, a globally unique identifier will be used by > the RS without the RC or the end-user knowing it. > Opaque tokens are in contradiction with the > end-user's privacy. > > For end-users caring about their privacy (or for systems willing to > protect the user's privacy), access tokens should not be considered > to be opaque to RCs, nor to RSs, and ASs should not support Token > Introspection, whether it is RS-Token Introspection or RC-Token > Introspection. > > Denis > > > 7. The content and the format of access tokens shall not be considered to >>>> be opaque to the RC so that the RC can inspect it. >>>> This is a matter of confidence to make sure for the RC (and for the >>>> user) that no "extra" information has been included by the AS into the >>>> access token. >>>> >>> [FI] This might go a bit further than the GNAP's mandate (especially if >> it becomes a mandatory requirement). But supposing we support non-opaque >> tokens, >> does it preclude supporting opaque tokens? It's just a different trust >> model, which makes sense if people agree with your premises (previous >> items), >> but that are less relevant if people still consider the AS as the central >> piece. Also one great thing with opaque tokens is that it makes the system >> easier to upgrade >> (you don't really care about what a token is). >> >> [Denis] Privacy is not more relevant for an AS-centric model than for a >> RS-centric model. In particular, a RC should be able to verify which kind >> of end-user identifier claim >> has been incorporated into the access token by the AS, in particular >> whether it is globally unique, unique to the AS only, unique to the RS only >> or ephemeral (valid for >> that RS during a session with the AS). >> > [FI2] ok, see discussion on whether tokens should be opaque or not. > >> I suppose that the use of structured access tokens should be recommended. >> This means,in particular, that from the very beginning, we should >> incorporate a version number >> inside each access token. >> >> One alternative way would be to allow RS call to AS for verification >> (including revocation status) and include a checksum. >> >> [Denis] The RC, i.e. not the RS, should be able to perform such >> verification before presenting the access token to the RS. So this >> alternative way would not work. >> > [FI2] then there could be a similar API for the client (cf discussion on > similarities between introspection/management APIs). > >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000086712205b632806c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

Please= note that the token introspection is not a new idea, it's already pres= ent in OAuth2 world (rfc 7662), and allows the RS to verify the access toke= n.

In the current version of GNAP, there is also s= ection 6 that introduces management endpoints, which could potentially be e= xtended in a similar way (currently this is not specified, the management e= ndpoint is here for rotation/revocation). Then the client could require mor= e information on what is included in the opaque token, but of course, this = relies on the assumption that the client trusts the AS.=C2=A0There is also = the discussion on the "resource" description in the response, tha= t may provide a simpler scheme (https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/141).=C2=A0
=C2=A0
But if we assume t= he AS may be malevolent=C2=A0(which is more likely if the AS becomes a less= central point, at least for some implementations), then indeed receiving o= paque tokens wouldn't provide all the guarantees, as it may lie on what= is really in the token (too many claims for instance).=C2=A0
Mor= e specifically, while I recon there might be a risk which we'd rather n= ot have, I don't really think an opaque token is really an unmanageable= issue with privacy. Suppose someone adds a field in a JWT, most likely you= 'll be able to detect that.=C2=A0

But suppose = we go for non opaque tokens, then we'd need a way of describing its for= mat. Which might limit a bit the use cases if we're not careful.=C2=A0<= /div>

I'd be interested to know what others think, s= ince it is diverging quite a bit from the OAuth2 world (not a bad thing in = itself but still).=C2=A0

Fabien

On Fri, Dec 1= 1, 2020 at 12:04 PM Denis <denis.i= etf@free.fr> wrote:
=20 =20 =20
Hi Fabien,

This is a response only to the point 7 from the "Quick review of draft-ietf-gnap-core-protocol-00"= .
The full original text with your comments is copied after my reply.

In order to allow the RC to understand the content of an opaque token, you are proposing to support a Token Introspection query from the RC to the AS.
This does not solve the concerns of a RC that wants to make sure that the access token does not contain claims that have not been requested.

Let us illustrate the case by using an example:

The RC asks to the AS to deliver an access token that contains an identifier only unique to the RS.
In reality, the AS delivers an access token that does contain an identifier only unique to the RS
but in addition a globally unique identifier. Since the access token is supposed to be opaque to the RC,
the RC calls the AS to perform a Token Introspection operation. In its response, the AS presents an identifier
that is indeed only unique to the RS but the AS voluntarily omits to present the globally unique identifier to the RC.

In the same way, if Token Introspection is supported by a RS, that does not provide confidence to the end-user or to the RC.

Let us illustrate the case by using another example:

The AS delivers to the RC an access token that only contains an identifier unique to the RS. Since the access token
is supposed to be opaque to the RS, the RS calls the AS to perform a Token Introspection operation. In its response,
the AS presents an identifier that is indeed only unique to the RS but the AS voluntarily adds a globally unique identifier.

Conclusion: In both cases, a globally unique identifier will be used by the RS without the RC or the end-user knowing it.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Opaque tokens are= in contradiction with the end-user's privacy.

For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
to be opaque to RCs, nor to RSs, and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

Denis


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
=C2=A0=C2=A0=C2=A0 This is a matter of confid= ence to make sure for the RC (and for the user) that no "extra" information has been includ= ed by the AS into the access token.

[FI] This might go a bit further than the GNAP's=C2=A0mandate (especially if= it becomes a mandatory requirement). But supposing we support non-opaque tokens,
does it preclude supporting opaque tokens? It's jus= t a different trust model, which makes sense if people agree with your premises (previous items),
but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade
(you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for
that RS during a session with the AS).

[FI2] ok, see discussion on whether tokens should be opaque or not.

I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number
inside each access token.


One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum.

[Denis]=C2=A0 The RC, i.e. not the RS, should be able to perfo= rm such verification before presenting the access token to the RS. So this alternative way would not work.

[FI2] then there could be a similar API for the client (cf discussion on similarities between introspection/management APIs).


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000086712205b632806c-- From nobody Fri Dec 11 09:02:18 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A90E3A0D27 for ; Fri, 11 Dec 2020 09:02:16 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ6pE9wS6Tnx for ; Fri, 11 Dec 2020 09:02:13 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 C1AA73A0CFE for ; Fri, 11 Dec 2020 09:02:12 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id d17so13288554ejy.9 for ; Fri, 11 Dec 2020 09:02:12 -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=eAtfUujReyylWIMIY+egfBF3cJyLCdiNTytXyrKnsnA=; b=gRJUSQDe85A2lQEA8x4DrvPZ5Q8XPJkNYiZhEgPVQoRnNlLd6Rv2wYC+vpfPuhS2i0 2C+UtiSVasJMWKAVc6ejd+YilocTwghtE0beFy4edUBapilWaLaVlDIw3NXyODVIzk3a PerKuZk5B+3Ip/KHPJ+utLCURXQUhTFRUb4+W2d6dvNH/VvPjBy/SJHsVhMUsyU4xV6O 49Gc3b3DgB5rTOP+tCBZuGOsrRDHTDcK72TGM0PduZlRWvNqpksqKOvm5dNJnQiEOX84 IKYmuAbrS+AUi+lRu+EkmCN2P8tt/zYtexapufNbqwYw8Sh8vVGJUkOGPLijPJl4VWC5 roxw== 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=eAtfUujReyylWIMIY+egfBF3cJyLCdiNTytXyrKnsnA=; b=I8HnbNl6WAGuBKMKQGJdq1Z0EMcrTpUGsI5UuZcmVjMWMuJcBqG36Mt7usZMqH4RYr L7B3ZcJwQggfe15L4Uk2CpLHLdVJ9jvYDV8VUrGXWJJTprkRRacK64ODUV+t7vYASd+5 S8WA496i5wtzipyYUXXo2khSV54fmW/PS5ZChpcj4qXyHsncomhssIt9f27dL75TJq7+ Df1ht64ZTkDKJxPkkQmo3nX387AMP0edri++naJIxScDMkHvxYxigTzTUMUcHQ8Lv+jK ayHHou9xuOuzKI5gHugM8H8Gm70oBg8wpHjGEE09FMkwjjQVYzpC4Kiw9LV40lgk7Rtu hKDQ== X-Gm-Message-State: AOAM532Cs6meLt7m1to3jep3AvP3/VuU2WZhYurXu+cRnb1+G1omL2lk X7pPw63UKOFw6hj0c1nnE2Q5YUFav1qjtw== X-Google-Smtp-Source: ABdhPJw7cbLL5rpaGUwb5QjdSuxg20E9xCFdCT7W/1lWPttkVoks8nuWkkQYcr8SS44YRtbHNoUkoQ== X-Received: by 2002:a17:906:b79a:: with SMTP id dt26mr11339954ejb.337.1607706131152; Fri, 11 Dec 2020 09:02:11 -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 n7sm8087747edb.34.2020.12.11.09.02.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2020 09:02:10 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Fri, 11 Dec 2020 19:02:08 +0200 From: Yaron Sheffer To: Fabien Imbault , Denis CC: GNAP Mailing List Message-ID: <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> Thread-Topic: [GNAP] Terminology proposal References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3690558129_1960921341" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 11 Dec 2020 17:02:17 -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_3690558129_1960921341 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fabien, =20 Yes, we definitely need to reach closure on terminology, thank you for driv= ing this discussion! =20 One process comment: unless I=E2=80=99m missing something, the Interact (or Inter= action) Server is not mentioned in the current draft. I suggest we do not in= troduce new functional components or new behaviors as part of the terminolog= y discussion. Specifically, if the IS is useful, let=E2=80=99s reach consensus on = that separately. Then we can add it into the Terminology section. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: TXAuth on behalf of Fabien Imbault Date: Friday, December 11, 2020 at 14:31 To: Denis Cc: GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hi Denis,=20 =20 Thanks for your detailed feedback. My comments are embedded into your messa= ge. Again those comments are my own, and we'll need to converge to some cons= ensus beyond what I say here. My main open question is really about the RO b= eing optional. Could you explain? =20 Fabien=20 =20 On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: This is a global response to the definitions proposal.=20 =20 Terminology I propose to adopt the way ISO defines how to write the definitions. It is a single sentence that may be substituted to the wording being define= d in the context of a sentence that uses that definition.=20 Since this single sentence can be substituted to the wording, there is not = point at the end of that sentence. The sentence does not=20 have a "a" or "the" in front of it. =20 [FI] In the first version, I was mostly trying to not get too far away from= the current text. But yes that's a good idea, it gives a more formal rule, = which has been proven to work.=20 =20 If more information is useful to understand the wording, it is placed in on= e or more notes afterwards. =20 Note: The ISO rules for drafting definitions are in the ISO/IEC Directives,= Part 2 (edition 2018): 16.5.6 Definitions The definition shall be written in such a form that it can replace the term= in its context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor= end with a full stop.=20 A definition shall not take the form of, or contain, a requirement. Only one definition per terminological entry is allowed. If a term is used = to define more than one concept, a separate terminological entry shall be cr= eated=20 for each concept and the domain shall be included in angle brackets before = the definition. Circular definitions, which repeat the term being defined, are not allowed. Comments are inserted between the lines. =20 Hello everyone, =20 =20 As an editor : a quick reminder that terminology issues will be discussed i= n the coming weeks, and we're expecting your inputs right now (according to = the process previously sent on the mailing list). https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology=20 =20 The rest of this message is a proposal written in my own name, and doesn't = involve discussions with the editors/chairs who might have different opinion= s. =20 Authorization Server (AS) Manages the granting of privileges to a third-party client instance. If the= RO consents to at least a part of what is requested, the AS issues an acces= s token to the client.=20 My questions:=20 - was else do we issue? (e.g. id claims, payment info, etc.) We could have = more than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I remo= ved that for now. - there might potentially be several AS, currently we don=E2=80=99t reflect that = anywhere. If would leave that as an open item, depending on what we end up d= oing in the spec I am not in favour of this definition: A RO as defined later: "authorizes t= he request to access a protected resource from the RS to the client".=20 This does not mean in any way that a RO has necessarily a direct relationsh= ip with one or more ASs. [FI] indeed we could remove that limitation, to hav= e a more general definition Using the ISO style for definitions, I propose: Authorization Server (AS): server that grants rights and/or attributes to a= particular end-user and that provides them to a client in the form of an ac= cess token Since this definition is using the words "rights" and "attributes", these t= wo terms need to be defined as well. right: ability for an end-user to perform a given operation on an object un= der the control of a RS attribute: property related to an end-user =20 [FI] I like your proposal in general. There might be some discussions on th= e details. I don't think it makes sense to grant "attributes". =20 Some explanations: a "right" is able to support a capability scheme. An "at= tribute" is able to support an ACL scheme.=20 These two schemes are able to support "discretionary access control" where = the end-user has a "need-to-know".=20 However, some attributes are also able to support what was called in the p= ast "mandatory access control"; for example,=20 if the end-user is cleared to "top-secret / marketing strategy". Interact Server (IS) - this is a new proposed term Manages the front-end interaction with the RO, in order to gather its conse= nt. Depending on the deployment model and the privacy requirements,=20 the IS may be a component of the AS, or may be distinct and managed by anot= her party. Example : an IS usually involves a web interface accessed by RO through a w= eb browser.=20 Note : an IS is not always required, especially if the access is granted th= rough automated policies. Using the ISO style for definitions, I propose: =20 Interaction Server (IS)=20 component from the AS or server interfacing with an AS that manages the int= eractions with a RO, in order to gather its authorization Note : since the RO is an optional component, the IS is also an optional co= mponent. =20 [FI] indeed IS is optional. note for myself when looking at RO : why is RO = optional ? =20 Client=20 Requests privileges from the AS, and uses access tokens at the RS. This spe= cification differentiates between a specific instance (the client instance, = identified by its unique public key)=20 and the software running the instance (the client software). . For some kin= ds of client software, there could be many instances of a single piece of cl= ient software. The AS determines which policies apply to a given client instance, includin= g what it can request and on whose behalf. Some comments: The above text is stating: "(the client instance, identified= by its unique public key)".=20 A client instance may use a public key, but that key is not necessarily uni= que, in particular when there are multiple ASs. [FI] yes, although when possible I would still consider a better practice t= o expose a key to a specific AS and not to the entire set of available ASs.=20 Example : a client can be a mobile application or a web application (the cl= ient software) that requires authorizations from the RO to retrieve content = from various protected APIs. The client instance may for instance refer to a= specific version of that client software. See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protoco= l/pull/132 (client instance).=20 Using the ISO style for definitions, I propose: Client: application used by an end-user to interact with an AS or a RS Note: a client can be a mobile application or a web application [FI] for me= those are just examples, because there could me more (ex IoT device) [FI] you remove the entire discussion on client instance / client software,= is that on purpose because you think it's not useful/right, or is it becaus= e of something else? (maybe add your comment of the related issue) =20 Resource Server (RS) Accepts valid access tokens from the client issued by the AS and serves pro= tected resources on behalf of the RO. There could be multiple RSs protected = by the AS that the client may call. Example : a RS is often composed of protected APIs that can be consumed by = authorized client software. =20 One comment: a RO is not necessarily involved. [FI] a bit hard to imagine, = there's some kind of owner. Could you be more explicit? Using the ISO style for definitions, I propose: Resource Server (RS): server that accepts valid access tokens from clients = issued by one or more ASs which are used to grant or deny some requested ope= rations Note: a RS is often composed of protected APIs that can be consumed by clie= nts. Resource Owner (RO) Authorizes the request to access a protected resource from the RS to the cl= ient. The RO may decide to remove its consent at any time. Note : the RO may be a physical person or may represent an organization. =20 Two comments: In order to avoid confusion with the end-user consent, the wo= rd " authorization" is being used instead of "consent". [FI] ok=20 It should be said that the RO is an optional component. [FI] why? Using the= ISO style for definitions, I propose: Resource Owner (RO): physical person acting on its own or representing an o= rganization that authorizes to clients operations on protected resources fro= m a RS Note: The RO is an optional component that may interact either with one RS = or with one or more ASs ,e.g. using an IS. End-user =E2=80=93 this was previously Requesting Party RQ A physical person that operates and interacts with the client software.=20 Note : the end-user may or may not be the same entity as the RO.=20 The Note is slightly incorrect. the physical person may or may not be the s= ame entity as the RO. [FI] I didn't understand your comment Using the ISO style for definitions, I propose: End-user : physical person that operates and interacts with the client sof= tware=20 Note : that physical person may or may not be the same entity as the RO.=20 =20 Access Token A set of privileges delegated to the client instance for a specific end-use= r. An access token is created by the AS, consumed and verified by the RS, an= d issued to and carried by the client's end-user on behalf of the RO. The co= ntents and format of the access token are opaque to the client. Example : JWT is a commonly used format.=20 Note 1 : an access token generally has a limited duration, after which it m= ay be refreshed at a regular interval. Note 2 : an access token may be revoked at any time by the RO.=20 Note 3 : an access token may act as a capability or require an additional a= uthentication by binding to a key=20 A fundamental point: the third sentence from the definition states: "The co= ntents and format of the access token are opaque to the client". [FI] I'll check your other thread dedicated to that issue=20 See my other email sent today about "RS-Token Introspection or RC-Token Int= rospection" where I conclude: For end-users caring about their privacy (or for systems willing to p= rotect the user's privacy), access tokens should not be considered to be opaque to RCs nor to RSs and ASs should not support Token Intro= spection, whether it is RS-Token Introspection or RC-Token Introspection. The example and the other Notes above should be removed. If needed they sho= uld be placed in the main body of the document. Using the ISO style for definitions, I propose:=20 Access Token : digitally signed data issued by an Authorization Server (AS)= and consumed by a Resource Server (RS)=20 that contains rights and/or attributes granted to = a particular end-user =20 Grant The process by which the client requests and is given delegated access to t= he RS by the AS through the authority of the RO. Using the ISO style for definitions, I propose: Grant: permission given to end-user to use a subset of his rights and/or hi= s attributes at a specific time and for a specific duration Key A public cryptographic binding a request to the holder of a private key. Ac= cess tokens and client instances can be associated with specific keys at a p= oint in time.=20 Note : a key can be rotated or revoked by its holder. The protocol supports= the update of the key information.=20 "key" is a general term that is well understood and that does not need to b= e defined. [FI] I really wouldn't bet on that. We can reuse an existing defi= nition but it is a central piece so we need to be explicit The "definitions" section is not intended to explain what can be done with = the term that is being defined. [FI] ok we can work on that Until the word "key" is qualified using one or more other terms, this defin= ition should be removed. Resource A protected API served by the RS and accessed by the client if and only if = access has been granted. Access to this resource is delegated by the RO as p= art of the grant process. The second sentence of the definition is not in accordance with the ISO sty= le or definitions and furthermore this second sentence should be removed sin= ce a RO is an optional element. =20 Using the ISO style for definitions, I propose:=20 Resource: protected API served by a RS and accessed by a client, if and onl= y if access is granted by an access token=20 Subject Information Information about a subject (usually a RO) that is returned directly to the= client from the AS. Note : this information needs to be unique.=20 =20 This definition exhibits several problems:=20 (1) The term "subject" is not defined.=20 (2) The information that is returned is for an end-user, i.e. not for "(usu= ally a RO)".=20 (3) The Note states : "this information needs to be unique". Does it mean u= nique for the AS ? globally unique ?=20 This definition should be revisited. [FI] I agree (I myself had many questi= ons here) Denis =20 My questions :=20 - probably we=E2=80=99d need to define subject Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697= /Subject+Dictionary+Entry - might be useful to clarify the relationship to what identity providers do= =20 =20 =20 Cheers Fabien =20 =20 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3690558129_1960921341 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Fabien,=

 

Yes, we defin= itely need to reach closure on terminology, thank you for driving this discu= ssion!

 

One process comment: unless I=E2=80=99m missing something, the Interact (or In= teraction) Server is not mentioned in the current draft. I suggest we do not= introduce new functional components or new behaviors as part of the termino= logy discussion. Specifically, if the IS is useful, let=E2=80=99s reach consensus = on that separately. Then we can add it into the Terminology section.

 

Thanks,

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

 

From: TXAuth <txauth-bounces@ietf.org> on behalf of= Fabien Imbault <fabien.imbault@gmail.com>
Date: Friday, Dec= ember 11, 2020 at 14:31
To: Denis <denis.ietf@free.fr>
Cc: GNAP Mailing List <txauth@ietf.org>
Subject: Re: [G= NAP] Terminology proposal

 

Hi Denis, 

 

Thanks for your detailed feedback. My comments are embedded into y= our message. Again those comments are my own, and we'll need to converge to = some consensus beyond what I say here. My main open question is really about= the RO being optional. Could you explain?

 

Fabien 

 

<= p class=3DMsoNormal>On Fri, Dec 11, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:

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

This is a global response to the definitions proposal.

 

Termino= logy

I propose to adopt= the way ISO defines how to write the definitions.

It is a single sentence that may be substituted to the wording being defined in the = context of a sentence that uses that definition.
Since this single sente= nce can be substituted to the wording, there is not point at the end of that= sentence. The sentence does not
have a "a" or "the"= in front of it.

 

[FI] In the first version, I was mostly trying to not get to= o far away from the current text. But yes that's a good idea, it gives a more fo= rmal rule, which has been proven to work. 

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

&= nbsp;

If more information is useful to understa= nd the wording, it is placed in one or more notes afterwards.

=

 

Note: The ISO rules for drafting definitions are in the ISO/IEC Directi= ves, Part 2 (edition 2018):

16.5.6   = ; Definitions

The definition shall be written in = such a form that it can replace the term in its context. It shall not start = with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end with a full stop.
A definit= ion shall not take the form of, or contain, a requirement.

Only one d= efinition per terminological entry is allowed. If a term is used to define m= ore than one concept, a separate terminological entry shall be created
f= or each concept and the domain shall be included in angle brackets before th= e definition.

Circular definitions, which repeat the term being defin= ed, are not allowed.

Comments are inserted between= the lines.

 

=

Hello everyone, 

 

As an editor : a quic= k reminder that terminology issues will be discussed in the coming week= s, and we're expecting your inputs right now (according to the process previ= ously sent on the mailing list).

 

The rest of this message is a proposal written in my own name, and d= oesn't involve discussions with the editors/chairs who might have different = opinions. 

<= span style=3D'font-size:10.0pt;line-height:125%;font-family:"Arial",sans-serif= ;color:#24292E'>Authorization Server (AS)

Manages the granting of privileges to a third-party cli= ent instance. If the RO consents to at least a part of what is requested, th= e AS issues an access token to the client.

My questions:

- was else do we issue? (e.g. id claims, payment in= fo, etc.) We could have more than access tokens, but =E2=80=9Cdirected information= =E2=80=9D is not clear. I removed that for now.

- there might potentially be several AS, currentl= y we don=E2=80=99t reflect that anywhere. If would leave that as an open item, dep= ending on what we end up doing in the spec

I am not in favour of this definition: A RO as defined later: &qu= ot;authorizes the request to access a protected resource from the RS to the = client".
This does not mean in any way that a RO has necessarily a = direct relationship with one or more ASs. [FI] indeed we could remove that limitation, to = have a more general definition

Using t= he ISO style for definitions, I propose:

Authorization Server (AS): server that= grants rights and/or attributes to a particular end-user and that provides = them to a client in the form of an access token

Since this def= inition is using the words "rights" an= d "attributes", these two terms need to be defined as well.=

right: ability fo= r an end-user to perform a given operation on an object under the control of= a RS

attribute: property related to an end-user

 

[FI] I like your proposal = in general. There might be some discussions on the details. I don't think it= makes sense to grant "attributes".   <= /o:p>

Some explanations: a "= right" is able to support a capability scheme. An "attribute"= is able to support an ACL scheme.

These two schemes are able to support &= quot;discretionary access control" where the end-user has a "need-= to-know".

However, some attributes are also able to support what = ; was called in the past "mandatory access control"; for example, =

if the end-user is cleared to "top-secret / marketing strategy".=



Interact Server (IS) - this is a new prop= osed term

Manages the front-end interaction with the RO, in = order to gather its consent. Depending on the deployment model and the priva= cy requirements,
the IS may be a component of the AS, or may be distinct= and managed by another party.

Example : an IS usually involves a web interface accessed by RO throug= h a web browser.

Note : = an IS is not always required, especially if the access is granted through au= tomated policies.

<= span style=3D'font-size:12.0pt;font-family:"Arial",sans-serif'>Using the ISO s= tyle for definitions, I propose:

 

<= h3 style=3D'mso-margin-top-alt:6.0pt;margin-right:0in;margin-bottom:0in;margin= -left:0in'>Interaction Server (IS)

component from the AS= or server interfacing with an AS that manages the interactions with a RO, i= n order to gather its authorization

N= ote : since the RO is an optional component, the IS is also an optional comp= onent.

 

[FI] indeed IS is optional. note for myself when looking at RO : why= is RO optional ?  

= Client

Requests privileges from the AS, and uses acce= ss tokens at the RS. This specification differentiates between a specific in= stance (the client instance, identified by its unique public key)
and th= e software running the instance (the client software). . For some kinds of c= lient software, there could be many instances of a single piece of client so= ftware.
The AS determines which policies apply to a given client instance= , including what it can request and on whose behalf.

= Some comments: The above text is stating: "(the client instance, identified by its unique public key)".
A= client instance may use a public key, but that key is not necessarily uniqu= e, in particular when there are multiple ASs.

<= /div>

[FI] yes, = although when possible I would still consider a better practice to expose a = key to a specific AS and not to the entire set of available ASs. 

=

Example : a client can be a mobile application or a web application (t= he client software) that requires authorizations from the RO to retrieve con= tent from various protected APIs. The client instance may for instance refer= to a specific version of that client software.

See on-going discussion : https://github.com/ietf-wg-g= nap/gnap-core-protocol/pull/132 (client instance).

Using the ISO style for defin= itions, I propose:

Client: application used by an end-us= er to interact with an AS or a RS

Note: a client can be a mobile a= pplication or a web application [FI] for me those are just examples, because there could m= e more (ex IoT device)

=

[FI] you remove the entire d= iscussion on client instance / client software, is that on purpose because y= ou think it's not useful/right, or is it because of something else? (maybe a= dd your comment of the related issue)   

Resource Server (RS)

Accepts valid access tokens from the client issued by t= he AS and serves protected resources on behalf of the RO. There could be mul= tiple RSs protected by the AS that the client may call.

Example : a RS is often composed of protec= ted APIs that can be consumed by authorized client software. 

One comment: a RO is not necessarily involve= d. [FI] a bit = hard to imagine, there's some kind of owner. Could you be more explicit?

Using the ISO style for definitions, I pr= opose:

Resource Server (RS): server that accepts valid access tokens from clien= ts issued by one or more ASs which are used to grant or deny some requested = operations

Note: a RS is often composed of protected APIs tha= t can be consumed by clients.



Resou= rce Owner (RO)

Author= izes the request to access a protected resource from the RS to the client. T= he RO may decide to remove its consent at any time.

Note : the RO may be a physical person or may = represent an organization.

 

Two comments: In order to avoid confusion wit= h the end-user consent, the word " authorization" is being used in= stead of "consent". [FI] ok 

It should be said that the RO i= s an optional component. [FI] why? Using the IS= O style for definitions, I propose:

Resource Owner (RO): physical person acting = on its own or representing an organization that authorizes to clients operat= ions on protected resources from a RS

Note: The RO is an opti= onal component that may interact either with one RS or with one or more ASs = ,e.g. using an IS.

End-user =E2=80=93 this was previously Requesting Part= y RQ

A physical person that operates and interacts with t= he client software.

N= ote : the end-user may or may not be the same entity as the RO. =

The Note is slightly incorrect. the physical person may or may not = be the same entity as the RO. [FI] I didn't u= nderstand your comment

Using th= e ISO style for definitions, I propose:

En= d-user :  physical person that operates and interacts with the client s= oftware

Note : that physical person may or may not be t= he same entity as the RO.

=  

Access Token=

A set of privileges delegat= ed to the client instance for a specific end-user. An access token is create= d by the AS, consumed and verified by the RS, and issued to and carried by t= he client's end-user on behalf of the RO. The contents and format of the acc= ess token are opaque to the client.

Example : JWT is a commonly used format.

Note 1 : an access token generally has a l= imited duration, after which it may be refreshed at a regular interval.

Note 2 : an access token m= ay be revoked at any time by the RO.

Note 3 : an access token may act as a capability or require an additional = authentication by binding to a key

A fundamental = point: the third sentence from the definition states: "The contents and format of the access token are opaque to the cl= ient".

[FI] I'll check your other thread dedicated t= o that issue 

See my other email sent today about "RS-Token Introspection or RC-T= oken Introspection" where I conclude:

<= span style=3D'font-family:"Arial",sans-serif'>      F= or end-users caring about their privacy (or for systems willing to protect t= he user's privacy), access tokens should not be considered
      to be o= paque to RCs nor to RSs and ASs should not support Token Introspection, whet= her it is RS-Token Introspection or RC-Token Introspection.

The example and the oth= er Notes above should be removed. If needed they should be placed in the mai= n body of the document.

Using the ISO style for de= finitions, I propose:

Access Token : digitally signed data issued by an Authorization Server (AS) and c= onsumed by a Resource Server (RS)
      &n= bsp;            =       that contains rig= hts and/or attributes granted to a particular end-user

 

Grant

The process by which the client requests and is given delegated ac= cess to the RS by the AS through the authority of the RO.<= /p>

Using the ISO style for definit= ions, I propose:

Grant: permission given to end-user t= o use a subset of his rights and/or his attributes at a specific time and fo= r a specific duration



=

Key

A public cryptographic binding a requ= est to the holder of a private key. Access tokens and client instances can b= e associated with specific keys at a point in time.

Note : a key can be rotated or revoked by its= holder. The protocol supports the update of the key information.

"key" is a general term that is wel= l understood and that does not need to be defined. [FI] I really wouldn't bet on that. We = can reuse an existing definition but it is a central piece so we need to be = explicit

The "definitions" section is not intended = to explain what can be done with the term that is being defined. [FI] ok we can work on th= at
Until the word "key" is qualified using one or more othe= r terms, this definition should be removed.



Resource

A protect= ed API served by the RS and accessed by the client if and only if access has= been granted. Access to this resource is delegated by the RO as part of the= grant process.

The second sentence = of the definition is not in accordance with the ISO style or definitions and= furthermore this second sentence should be removed since a RO is an optiona= l element.

 

Using the ISO style= for definitions, I propose:

Resource: protected API served by a = RS and accessed by a client, if and only if access is granted by an access t= oken

Subject Informa= tion

Information about a = subject (usually a RO) that is returned directly to the client from the AS.<= /span>

Note : this information ne= eds to be unique.

=  

This definition= exhibits several problems:

(1) The term "subject" is not defined.

(2) The inform= ation that is returned is for an end-user, i.e. = not for "(usually a RO)".

(3) The Note states : "this information needs to be u= nique". Does it mean unique for the AS ? globally unique ? =

This definition should be revisited. [FI] I agree (I myself had many ques= tions here)

Denis

 

My que= stions :

- probabl= y we=E2=80=99d need to define subject

Subject : https://open= -measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Ent= ry

- might be u= seful to clarify the relationship to what identity providers do =

 = ;

 

Cheers

Fabien

 

 

&nb= sp;



 

--
TXAuth mailing l= ist
TXAuth@ietf.org<= br>ht= tps://www.ietf.org/mailman/listinfo/txauth

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

--B_3690558129_1960921341-- From nobody Fri Dec 11 09:05:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE153A0D32 for ; Fri, 11 Dec 2020 09:05: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=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 GlFOt6PsNftr for ; Fri, 11 Dec 2020 09:05:14 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44A33A0CFE for ; Fri, 11 Dec 2020 09:05:14 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id o8so10196220ioh.0 for ; Fri, 11 Dec 2020 09:05: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=AN8605d40DbWZP9Dvoaz9K4XLwVRWQWI7hm6rzrtQyo=; b=FR0vZjyO9tP4IC+ahJjDRQTpUjvdT5vFpRnE4nb2UvnsxlURKcUfeualjf2GraQAqU NF1HMIXVxvJAnJ02lVm6h8BAbPHRc/UaYWfjnLfOYJcB6b1I8yijm7FQbQ7BKLcWFwFT oV/d7S+CyCWcYtpPldiv9IlVVE46QKi7+iJ31wdu7I8f4LjUWNMVsE3WR2ggui+o025M U1xyEZeLa4iRVjOGW0i9x6dBtURDLRW0jk9RloWRtFI7cCDTm/K+SK4X+ZguX285lh4z 4nBFucEblJH+PXFUVkHZH1+9PbZs04EgMkqB1U2NWYJmeDSfl6o4BDljZyBI0NrbvPcX b6UQ== 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=AN8605d40DbWZP9Dvoaz9K4XLwVRWQWI7hm6rzrtQyo=; b=gXBlS5wzwOAtMAPJaxNxNH83EaQW6ltosWJmB/RulsyfiowV9XtEqRrWgmoCsKP/dd r3yxE1e9by0MjksIYBBDQJfc2MIj+9HlnPYJrm1eXYAisHBIKq+RGE9KAAFCtBkrJS5b aIbzHbCR2v8Nrr4phN8hsJFceiYr2PPPWAZ+pGmT/wTjRkxZjPATVccvA82xXkvTfWU+ qS+6aNVYGVo7ZEy0enBJcPQrWusW/fTqswv3+DcO5QwA+1fCVPJjHUu2npcqLAvZm59S q0EdVtCgKOQJN5HFZmnskqLgJgdWIr+bNt3jFBbB3G2BzRBpkxABvS5MFmE5ez2Gx/pH VDZw== X-Gm-Message-State: AOAM531Mj+XOaKimOz3yh7hAlUwC2iJsZjXJKXlZIo6qvCX3nIYdVydp YpDPtMD3pMaeX9t+GAhA7hF/U9tIClxeFk5G/Ts= X-Google-Smtp-Source: ABdhPJxbDOZbyo7EAZuqUxprLyTuCf1czDEGqq76Mcb0seuMqNMC51doHvvqxCaA/KfSx16PKA2ljF/dxcd5+WkH6Z0= X-Received: by 2002:a02:5148:: with SMTP id s69mr17064773jaa.8.1607706312988; Fri, 11 Dec 2020 09:05:12 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> In-Reply-To: <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> From: Fabien Imbault Date: Fri, 11 Dec 2020 18:05:01 +0100 Message-ID: To: Yaron Sheffer Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b05b5605b6334bf2" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 11 Dec 2020 17:05:18 -0000 --000000000000b05b5605b6334bf2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Yes I highlighted that this was a new term. We can deal with it as a separate issue indeed. Best Fabien On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer wrote= : > Hi Fabien, > > > > Yes, we definitely need to reach closure on terminology, thank you for > driving this discussion! > > > > One process comment: unless I=E2=80=99m missing something, the Interact (= or > Interaction) Server is not mentioned in the current draft. I suggest we d= o > not introduce new functional components or new behaviors as part of the > terminology discussion. Specifically, if the IS is useful, let=E2=80=99s = reach > consensus on that separately. Then we can add it into the Terminology > section. > > > > Thanks, > > Yaron > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Friday, December 11, 2020 at 14:31 > *To: *Denis > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hi Denis, > > > > Thanks for your detailed feedback. My comments are embedded into your > message. Again those comments are my own, and we'll need to converge to > some consensus beyond what I say here. My main open question is really > about the RO being optional. Could you explain? > > > > Fabien > > > > On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: > > This is a global response to the definitions proposal. > > > TerminologyI propose to adopt the way ISO defines how to write the > definitions.It is a *single sentence* that may be substituted to the > wording being defined in the context of a sentence that uses that > definition. > Since this single sentence can be substituted to the wording, there is no= t > point at the end of that sentence. The sentence does not > have a "a" or "the" in front of it. > > > > [FI] In the first version, I was mostly trying to not get too far away > from the current text. But yes that's a good idea, it gives a more formal > rule, which has been proven to work. > > > > If more information is useful to understand the wording, it is placed in > one or more notes afterwards. > > > > Note: The ISO rules for drafting definitions are in the ISO/IEC > Directives, Part 2 (edition 2018): > > 16.5.6 Definitions > > The definition shall be written in such a form that it can replace the > term in its context. It shall not start with an article (=E2=80=9Cthe=E2= =80=9D, =E2=80=9Ca=E2=80=9D) nor > end with a full stop. > A definition shall not take the form of, or contain, a requirement. > > Only one definition per terminological entry is allowed. If a term is use= d > to define more than one concept, a separate terminological entry shall be > created > for each concept and the domain shall be included in angle brackets befor= e > the definition. > > Circular definitions, which repeat the term being defined, are not allowe= d. > > Comments are inserted between the lines. > > > > Hello everyone, > > > > As an editor : a quick reminder that terminology issues will be discussed > in the coming weeks, and we're expecting your inputs right now (according > to the process previously sent on the mailing list). > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 > > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > > > > The rest of this message is a proposal written in my own name, and doesn'= t > involve discussions with the editors/chairs who might have different > opinions. > Authorization Server (AS) > > Manages the granting of privileges to a third-party client instance. If > the RO consents to at least a part of what is requested, the AS issues an > access token to the client. > > *My questions: * > > *- was else do we issue? (e.g. id claims, payment info, etc.) We could > have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D = is not clear. I > removed that for now.* > > *- there might potentially be several AS, currently we don=E2=80=99t refl= ect that > anywhere. If would leave that as an open item, depending on what we end u= p > doing in the spec* > > I am not in favour of this definition: A RO as defined later: "authorizes > the request to access a protected resource from the RS to the client". > This does not mean in any way that a RO has necessarily a direct > relationship with one or more ASs. [FI] indeed we could remove that > limitation, to have a more general definition > Using the ISO style for definitions, I propose: > > Authorization Server (AS): server that grants rights and/or attributes to > a particular end-user and that provides them to a client in the form of a= n > access token > > Since this definition is using the words "rights" and "attributes", these > two terms need to be defined as well. > > right: ability for an end-user to perform a given operation on an object > under the control of a RS > > attribute: property related to an end-user > > > > [FI] I like your proposal in general. There might be some discussions on > the details. I don't think it makes sense to grant "attributes". > > Some explanations: a "right" is able to support a capability scheme. An > "attribute" is able to support an ACL scheme. > > These two schemes are able to support "discretionary access control" wher= e > the end-user has a "need-to-know". > > However, some attributes are also able to support what was called in the > past "mandatory access control"; for example, > > if the end-user is cleared to "top-secret / marketing strategy". > > > > Interact Server (IS) - this is a new proposed term > > Manages the front-end interaction with the RO, in order to gather its > consent. Depending on the deployment model and the privacy requirements, > the IS may be a component of the AS, or may be distinct and managed by > another party. > > Example : an IS usually involves a web interface accessed by RO through a > web browser. > > Note : an IS is not always required, especially if the access is granted > through automated policies. > > Using the ISO style for definitions, I propose: > > > > Interact*ion* Server (IS) > > component from the AS or server interfacing with an AS that manages the > interactions with a RO, in order to gather its authorizationNote : since > the RO is an optional component, the IS is also an optional component. > > > > [FI] indeed IS is optional. note for myself when looking at RO : why is R= O > optional ? > > Client Requests privileges from the AS, and uses access tokens at the RS. > This specification differentiates between a specific instance (the client > instance, identified by its unique public key) > and the software running the instance (the client software). . For some > kinds of client software, there could be many instances of a single piece > of client software. > The AS determines which policies apply to a given client instance, > including what it can request and on whose behalf. > > Some comments: The above text is stating: "(the client instance, > identified by its unique public key)". > A client instance may use a public key, but that key is not necessarily > unique, in particular when there are multiple ASs. > > [FI] yes, although when possible I would still consider a better practice > to expose a key to a specific AS and not to the entire set of available > ASs. > > Example : a client can be a mobile application or a web application (the > client software) that requires authorizations from the RO to retrieve > content from various protected APIs. The client instance may for instance > refer to a specific version of that client software. > > *See on-going discussion : > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 > (client > instance). * > > Using the ISO style for definitions, I propose: > > Client: application used by an end-user to interact with an AS or a RS > > Note: a client can be a mobile application or a web application [FI] for > me those are just examples, because there could me more (ex IoT device) > > [FI] you remove the entire discussion on client instance / client > software, is that on purpose because you think it's not useful/right, or = is > it because of something else? (maybe add your comment of the related > issue) > > Resource Server (RS) > > Accepts valid access tokens from the client issued by the AS and serves > protected resources on behalf of the RO. There could be multiple RSs > protected by the AS that the client may call. > > Example : a RS is often composed of protected APIs that can be consumed b= y > authorized client software. > > One comment: a RO is not necessarily involved. [FI] a bit hard to > imagine, there's some kind of owner. Could you be more explicit? > Using the ISO style for definitions, I propose: > > Resource Server (RS): server that accepts valid access tokens from client= s > issued by one or more ASs which are used to grant or deny some requested > operations > > Note: a RS is often composed of protected APIs that can be consumed by > clients. > > > > Resource Owner (RO) > > Authorizes the request to access a protected resource from the RS to the > client. The RO may decide to remove its consent at any time. > > Note : the RO may be a physical person or may represent an organization. > > > > Two comments: In order to avoid confusion with the end-user consent, the > word " authorization" is being used instead of "consent". [FI] ok > > It should be said that the RO is an optional component. [FI] why? Using > the ISO style for definitions, I propose: > > Resource Owner (RO): physical person acting on its own or representing an > organization that authorizes to clients operations on protected resources > from a RS > > Note: The RO is an optional component that may interact either with one R= S > or with one or more ASs ,e.g. using an IS. > > End-user =E2=80=93 this was previously Requesting Party RQ > > A physical person that operates and interacts with the client software. > > Note : the end-user may or may not be the same entity as the RO. > > The Note is slightly incorrect. the *physical person* may or may not be > the same entity as the RO. [FI] I didn't understand your comment > Using the ISO style for definitions, I propose: > > End-user : physical person that operates and interacts with the client > software > > Note : that physical person may or may not be the same entity as the RO. > > > > Access Token > > A set of privileges delegated to the client instance for a specific > end-user. An access token is created by the AS, consumed and verified by > the RS, and issued to and carried by the client's end-user on behalf of t= he > RO. The contents and format of the access token are opaque to the client. > > Example : JWT is a commonly used format. > > Note 1 : an access token generally has a limited duration, after which it > may be refreshed at a regular interval. > > Note 2 : an access token may be revoked at any time by the RO. > > Note 3 : an access token may act as a capability or require an additional > authentication by binding to a key > > A fundamental point: the third sentence from the definition states: "The > contents and format of the access token are opaque to the client". > > [FI] I'll check your other thread dedicated to that issue > > See my other email sent today about "RS-Token Introspection or RC-Token > Introspection" where I conclude: > > For end-users caring about their privacy (or for systems willing to > protect the user's privacy), access tokens should not be considered > to be opaque to RCs nor to RSs and ASs should not support Token > Introspection, whether it is RS-Token Introspection or RC-Token > Introspection. > > The example and the other Notes above should be removed. If needed they > should be placed in the main body of the document. > > Using the ISO style for definitions, I propose: > > Access Token : digitally signed data issued by an Authorization Server > (AS) and consumed by a Resource Server (RS) > that contains rights and/or attributes granted > to a particular end-user > > > > Grant > > The process by which the client requests and is given delegated access to > the RS by the AS through the authority of the RO. > > Using the ISO style for definitions, I propose: > > Grant: permission given to end-user to use a subset of his rights and/or > his attributes at a specific time and for a specific duration > > > > Key > > A public cryptographic binding a request to the holder of a private key. > Access tokens and client instances can be associated with specific keys a= t > a point in time. > > Note : a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > "key" is a general term that is well understood and that does not need to > be defined. [FI] I really wouldn't bet on that. We can reuse an existing > definition but it is a central piece so we need to be explicit > > The "definitions" section is not intended to explain what can be done wit= h > the term that is being defined. [FI] ok we can work on that > Until the word "key" is qualified using one or more other terms, this > definition should be removed. > > > > Resource > > A protected API served by the RS and accessed by the client if and only i= f > access has been granted. Access to this resource is delegated by the RO a= s > part of the grant process. > > The second sentence of the definition is not in accordance with the ISO > style or definitions and furthermore this second sentence should be remov= ed > since a RO is an optional element. > > > Using the ISO style for definitions, I propose: > > Resource: protected API served by a RS and accessed by a client, if and > only if access is granted by an access token > > Subject Information > > Information about a subject (usually a RO) that is returned directly to > the client from the AS. > > Note : this information needs to be unique. > > > > This definition exhibits several problems: > > (1) The term "subject" is not defined. > > (2) The information that is returned is for an end-user, i.e. not for "(u= sually > a RO)". > > (3) The Note states : "this information needs to be unique". Does it mean > unique for the AS ? globally unique ? > > This definition should be revisited. [FI] I agree (I myself had many > questions here) > > Denis > > > > *My questions : * > > *- probably we=E2=80=99d need to define subject* > > *Subject : > https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject= +Dictionary+Entry > * > > *- might be useful to clarify the relationship to what identity providers > do * > > > > > > 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 > --000000000000b05b5605b6334bf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,=C2=A0

Yes I highlighted that = this was a new term. We can deal with it as a separate issue indeed.=C2=A0<= /div>

Best
Fabien

On Fri, Dec 11, 2020 at= 6:02 PM Yaron Sheffer <yaronf.= ietf@gmail.com> wrote:

= Hi Fabien,

=C2=A0

=

Yes, we definitely need to reach closure on terminol= ogy, thank you for driving this discussion!

=C2=A0

One process comment= : unless I=E2=80=99m missing something, the Interact (or Interaction) Serve= r is not mentioned in the current draft. I suggest we do not introduce new = functional components or new behaviors as part of the terminology discussio= n. Specifically, if the IS is useful, let=E2=80=99s reach consensus on that= separately. Then we can add it into the Terminology section.=

=C2=A0

T= hanks,

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

=C2=A0

From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault &= lt;fabien.imb= ault@gmail.com>
Date: Friday, December 11, 2020 at 14:31To: Denis <denis.ietf@free.fr>
Cc: GNAP Mailing List <txauth@ietf.org>
Subject: Re: [GNAP] Terminology proposal

=C2=A0

Hi Denis,=C2=A0

=C2=A0

Thanks for you= r detailed feedback. My comments are embedded into your message. Again thos= e comments are my own, and we'll need to converge to some consensus bey= ond what I say here. My main open question is really about the RO being opt= ional. Could you explain?

=C2=A0

Fabien=C2=A0=

=C2=A0

<= div>

On Fri, Dec 11, 2020 at 12:08 PM Denis <= denis.ietf@free.fr<= /a>> wrote:

The defi= nition shall be written in such a form that it can replace the term in its = context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80= =9Ca=E2=80=9D) nor end with a full stop.
A definition shall not take th= e form of, or contain, a requirement.

Only one definition per termin= ological entry is allowed. If a term is used to define more than one concep= t, a separate terminological entry shall be created
for each concept an= d the domain shall be included in angle brackets before the definition.
=
Circular definitions, which repeat the term being defined, are not allo= wed.

=

The rest of this message is a proposal written in my own name, and d= oesn't involve discussions with the editors/chairs who might have diffe= rent opinions.=C2=A0

Authorization Server (AS)

Manages the granting of privileges to a third-par= ty client instance. If the RO consents to at least a part of what is reques= ted, the AS issues an access token to the client.

=

My questions:

- was else do we = issue? (e.g. id claims, payment info, etc.) We could have more than access = tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I removed = that for now.

- there might potentially be several AS, currently we don=E2=80= =99t reflect that anywhere. If would leave that as an open item, depending = on what we end up doing in the spec

I am no= t in favour of this definition: A RO as defined later: "authorizes the= request to access a protected resource from the RS to the client". This does not mean in any way that a RO has necessarily a direct relation= ship with one or more ASs. [FI] indeed we could remove that limitation, to have a more g= eneral definition

Using the ISO style for definitions, I = propose:

Authori= zation Server (AS): server that grants rights and/or attributes to a partic= ular end-user and that provides them to a client in the form of an access t= oken

Since this definition is using the words "rights" and "attributes", these two terms need to b= e defined as well.

right: abil= ity for an end-user to perform a given operation on an object under the con= trol of a RS

attr= ibute: property related to an end-user

=C2=A0

[FI] I like your p= roposal in general. There might be some discussions on the details. I don&#= 39;t think it makes sense to grant "attributes".=C2=A0=C2=A0=C2=A0

Some explanations: a "right" is able to suppor= t a capability scheme. An "attribute" is able to support an ACL s= cheme.

These two= schemes are able to support "discretionary access control" where= the end-user has a "need-to-know".

However, some attributes are also able to sup= port what=C2=A0 was called in the past "mandatory access control"= ; for example,

i= f the end-user is cleared to "top-secret / marketing strategy".



Interact Server (IS) - this is a new propose= d term

<= p style=3D"margin-bottom:0.1in;line-height:150%">Manages the front-end interaction wi= th the RO, in order to gather its consent. Depending on the deployment mode= l and the privacy requirements,
the IS may be a component of the AS, or= may be distinct and managed by another party.

Example : an IS usually involves a web = interface accessed by RO through a web browser.

Note : an IS is not always required, = especially if the access is granted through automated policies.

Using the ISO style for definitions, I propose:

=C2=A0

Interaction Server (IS)

comp= onent from the AS or server interfacing with an AS that manages the interac= tions with a RO, in order to gather its authorization<= /h3>

No= te : since the RO is an optional component, the IS is also an optional comp= onent.

=C2=A0

= [FI] indeed IS is optional. note for myself when = looking at RO : why is RO optional ?=C2=A0=C2=A0

Client

Requests privileges from the AS, and uses access tokens at the RS. Thi= s specification differentiates between a specific instance (the client inst= ance, identified by its unique public key)
and the software running the= instance (the client software). . For some kinds of client software, there= could be many instances of a single piece of client software.
The AS de= termines which policies apply to a given client instance, including what it= can request and on whose behalf.=

Some comments: The above text = is stating: "(the client instance,= identified by its unique public key)".
A client instance may use = a public key, but that key is not necessarily unique, in particular when th= ere are multiple ASs.

[FI] yes, although when= possible I would still consider a better practice to expose a key to a spe= cific AS and not to the entire set of available ASs.=C2=A0=

Example : a client can be a mobile applicat= ion or a web application (the client software) that requires authorizations= from the RO to retrieve content from various protected APIs. The client in= stance may for instance refer to a specific version of that client software= .

See on-going discussion : = https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132<= /a> (client instance).

Usin= g the ISO style for definitions, I propose:

Client: application used by an e= nd-user to interact with an AS or a RS

Note: a client can be a mobile applicat= ion or a web application [FI] for me those are just examples, because there could me mor= e (ex IoT device)

<= div>

[FI] you remove the en= tire discussion on client instance / client software, is that on purpose be= cause you think it's not useful/right, or is it because of something el= se? (maybe add your comment of the related issue)=C2=A0 =C2=A0

One comment: a RO is not necessarily involved. [FI] a bit hard to= imagine, there's some kind of owner. Could you be more explicit?

Using the ISO style for definitions, I propose:<= u>

Resource Server (RS): server = that accepts valid access tokens from clients issued by one or more ASs whi= ch are used to grant or deny some requested operations=

Note: a RS is oft= en composed of protected APIs that can be consumed by clients.



<= blockquote style=3D"margin-top:5pt;margin-bottom:5pt">

Resource Owner (RO)

Authorizes the request to access a prot= ected resource from the RS to the client. The RO may decide to remove its c= onsent at any time.

Note : the RO may be a physical person or may represent an organ= ization.

=C2=A0

Two comments: In order to avoid confusion with the end-user consen= t, the word " authorization" is being used instead of "conse= nt". [FI= ] ok=C2=A0

It should be said that the RO is an optional component.=C2=A0[FI] why? Using the ISO style for definitions, I p= ropose:

Resource = Owner (RO): physical person acting on its own or representing an organizati= on that authorizes to clients operations on protected resources from a RS

Note: The RO is an optional component that may interact either with one R= S or with one or more ASs ,e.g. using an IS.

The Note is sligh= tly incorrect. the physical person may or may not be the same en= tity as the RO. [FI] I didn't understa= nd your comment

Using the ISO style for definition= s, I propose:

End-user :=C2=A0 physical person that oper= ates and interacts with the client software

Note : that = physical person may or may not be the same entity as the RO. =

=C2=A0

A fundamenta= l point: the third sentence from the definition states: "The contents and format of the access token are op= aque to the client".

[FI] I'll check = your other thread dedicated to that issue=C2=A0

See my oth= er email sent today about "RS-Token Introspection or RC-Token Introspe= ction" where I conclude:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For end-users caring about thei= r privacy (or for systems willing to protect the user's privacy), acces= s tokens should not be considered
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to be opaque to RCs nor to RSs= and ASs should not support Token Introspection, whether it is RS-Token Int= rospection or RC-Token Introspection.

The example and the other Notes above sh= ould be removed. If needed they should be placed in the main body of the do= cument.

Using the ISO style for definitions= , I propose:

Acc= ess Token : digitally s= igned data issued by an Authorization Server (AS) and consumed by a Resourc= e Server (RS)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 that contains rights and/o= r attributes granted to a particular end-user

=C2=A0

Using the ISO style for definitions, I propose:

Grant: permission given to end-user to use a sub= set of his rights and/or his attributes at a specific time and for a specif= ic duration



Key

A public cryptographic binding a request= to the holder of a private key. Access tokens and client instances can be = associated with specific keys at a point in time.

=

Note : a key can be rotated or re= voked by its holder. The protocol supports the update of the key informatio= n.

"key" is a general term that is w= ell understood and that does not need to be defined. [FI] I really wouldn't bet on t= hat. We can reuse an existing definition but it is a central piece so we ne= ed to be explicit

The "definitions" section is not intended to= explain what can be done with the term that is being defined. [FI] ok we can work on th= at
Until the word "key" is qualified using one or= more other terms, this definition should be removed.<= u>



The second s= entence of the definition is not in accordance with the ISO style or defini= tions and furthermore this second sentence should be removed since a RO is = an optional element.

=C2=A0

Using the ISO style for definitions, I propose= : =

R= esource: protected API served by a RS and accessed by a client, if and only= if access is granted by an access token

Subject Information

Information about a subject (usual= ly a RO) that is returned directly to the client from the AS.=

Note : this information ne= eds to be unique.

=C2=A0

This definition exhibits= several problems:

(1) The term &quo= t;subject" is not defined.

(2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

=

(3) The Note states := "this information needs to be unique". Does it mean unique for t= he AS ? globally unique ?

This definition should be revisi= ted. [FI] I a= gree (I myself had many questions here)

Denis=

=

=C2=A0

My questions :

- probably we=E2=80= =99d need to define subject

Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subjec= t+Dictionary+Entry

- might be useful to clarify the relationship to what iden= tity providers do=C2=A0

=C2=A0

=C2=A0

Cheers

Fabien

<= /div>

=C2=A0

=C2=A0

<= u>=C2=A0



=C2=A0

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

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

--000000000000b05b5605b6334bf2-- From nobody Fri Dec 11 09:08:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A02F3A0CFE for ; Fri, 11 Dec 2020 09:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpNgnSMFqK_7 for ; Fri, 11 Dec 2020 09:08:00 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547F83A0D2C for ; Fri, 11 Dec 2020 09:07:59 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BBH7u3b028178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 12:07:57 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DB2305AE-13B9-49AE-832B-2BB6F6894596" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 11 Dec 2020 12:07:56 -0500 In-Reply-To: Cc: Warren Parad , Dick Hardt , txauth gnap To: Fabien Imbault References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 17:08:03 -0000 --Apple-Mail=_DB2305AE-13B9-49AE-832B-2BB6F6894596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Consistency and clarity for client developers is the goal with the = proposed PR. Since the =E2=80=9Ccontinue=E2=80=9D set of functions was = refactored to be an API, the thought was to treat this API exactly like = we=E2=80=99d treat an external API hosted at an RS. This pattern would = allow the AS to reap the benefits of a token-based protocol (distributed = deployments, better security, and so on) as well as making the client = developer=E2=80=99s life easier by not making them do something special = just to talk to the AS. As Fabien points out, the =E2=80=9Caccess_token=E2=80=9D field is = exactly the same field as what comes back in a response for a separate = API. The semantics of everything in that field are exactly the same in = both places, including the =E2=80=9Ckey=E2=80=9D field. The only = difference, right now, is that the =E2=80=9Ckey=E2=80=9D field is only = allowed to have one value, to indicate it=E2=80=99s bound to the = requesting client=E2=80=99s instance key that was used in the initial = request. There=E2=80=99s been some confusion on that, and so it=E2=80=99s = something we might want to change =E2=80=94 but that=E2=80=99s a = separate issue, and if we use access tokens for continuation then we can = solve that problem in a consistent way. When the client is continuing, you can think of the key presentation as = it =E2=80=9Cauthenticating=E2=80=9D, but I=E2=80=99d argue that you = don=E2=80=99t need to =E2=80=9Cauthenticate=E2=80=9D the client at this = stage: you just need the context of the ongoing request, and you need to = make sure that the caller of that request is the right caller. That is, = they can present the right set of security material. A key-bound access = token is the perfect map to this function, and it=E2=80=99s something we = already want as a core artifact. It also has the benefit of allowing = different parts of the AS to communicate via the access token itself = without things getting leaked in the URL. Could we put all that state in = the URL itself? Sure, but then we need to include discussion about how = to protect all of that. Instead, we have an opportunity to avoid = problems that we already know exist, instead of repeating them and = requiring fixes out of the gate. GNAP is our opportunity to do things = better than before. It=E2=80=99s been argued that a client that isn=E2=80=99t dealing with = access tokens at all would need to know something =E2=80=9Cnew=E2=80=9D = to deal with this continuation API. While technically true, the = difference between signing a request that includes an access token and = signing a request that doesn=E2=80=99t include an access token is = minimal. Further, I personally think that the use case for clients who = aren=E2=80=99t going to have any access tokens is going to be = exceedingly small, and so optimizing the protocol for that use case is a = big lose for the wider community. =E2=80=94 Justin > On Dec 11, 2020, at 9:17 AM, Fabien Imbault = wrote: >=20 > Hi,=20 >=20 > I commented previously on Dick's input (in short, I disagree - at = least with the cookie comparison). >=20 > I'm not sure I follow your point here. "access_token" already has its = field, the proposal is just reusing it throughout the protocol (see for = instance section 3.2.1) as a fairly consistent api. The only difference = is the meaning of the "key" boolean parameter (which I would be in favor = of renaming to clarify). >=20 > The proposed alternative comes with issues with seem very hard to get = around, at least in a systematic way. Like potential logs of capability = URLs that include the token, which opens the doors to vulnerable = implementations.=20 >=20 > Fabien >=20 > On Fri, Dec 11, 2020 at 11:24 AM Warren Parad > wrote: > For the part I agree with Dick, but I also dislike the separation of = the "access token" into its own field. If I understand continue = correctly, the access_token would only ever be used with the continue = uri, in which case, having the token in the url is much better than = having a separate parameter which has to be merged with the continue = request to auth it. In my opinion there is no reason to break HATEOAS = here, this is one of the few places where the capability URL makes = sense, and given its limited use and accessibility the concerns are = alleviated. Additionally moving the token back into the uri, avoids the = whole problem of naming and how to treat this token. >=20 >=20 > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . >=20 >=20 > On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt > wrote: > -1 per all the reasons I laid out in = https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ = > =E1=90=A7 >=20 > On Thu, Dec 10, 2020 at 7:52 AM Justin Richer > wrote: > The editors and chairs would like to confirm consensus on a current = pull request: >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 = >=20 > This pull request simplifies the continuation response and request by = making the access token mandatory, and it clarifies the responsibilities = of the AS in enforcing the security of the continuation request. Several = WG members expressed specific support for keeping the access token to = enable specific use cases, and there was general support for simplifying = the process from what it currently is in the draft. The editors believe = the pull request represents a solution that meets these goals. >=20 > This call is open until Monday December 14. At that point, the PR will = be merged unless the chairs determine there is not rough consensus for = its inclusion. >=20 > Thank you, >=20 > - Justin, Aaron, and Fabien > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_DB2305AE-13B9-49AE-832B-2BB6F6894596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Consistency and clarity for client developers is the goal = with the proposed PR. Since the =E2=80=9Ccontinue=E2=80=9D set of = functions was refactored to be an API, the thought was to treat this API = exactly like we=E2=80=99d treat an external API hosted at an RS. This = pattern would allow the AS to reap the benefits of a token-based = protocol (distributed deployments, better security, and so on) as well = as making the client developer=E2=80=99s life easier by not making them = do something special just to talk to the AS.

As Fabien points out, the = =E2=80=9Caccess_token=E2=80=9D field is exactly the same field as what = comes back in a response for a separate API. The semantics of everything = in that field are exactly the same in both places, including the = =E2=80=9Ckey=E2=80=9D field. The only difference, right now, is that the = =E2=80=9Ckey=E2=80=9D field is only allowed to have one value, to = indicate it=E2=80=99s bound to the requesting client=E2=80=99s instance = key that was used in the initial request. There=E2=80=99s been some = confusion on that, and so it=E2=80=99s something we might want to change = =E2=80=94 but that=E2=80=99s a separate issue, and if we use access = tokens for continuation then we can solve that problem in a consistent = way.

When the = client is continuing, you can think of the key presentation as it = =E2=80=9Cauthenticating=E2=80=9D, but I=E2=80=99d argue that you don=E2=80= =99t need to =E2=80=9Cauthenticate=E2=80=9D the client at this stage: = you just need the context of the ongoing request, and you need to make = sure that the caller of that request is the right caller. That is, they = can present the right set of security material. A key-bound access token = is the perfect map to this function, and it=E2=80=99s something we = already want as a core artifact. It also has the benefit of allowing = different parts of the AS to communicate via the access token itself = without things getting leaked in the URL. Could we put all that state in = the URL itself? Sure, but then we need to include discussion about how = to protect all of that. Instead, we have an opportunity to avoid = problems that we already know exist, instead of repeating them and = requiring fixes out of the gate. GNAP is our opportunity to do things = better than before.

It=E2=80=99= s been argued that a client that isn=E2=80=99t dealing with access = tokens at all would need to know something =E2=80=9Cnew=E2=80=9D to deal = with this continuation API. While technically true, the difference = between signing a request that includes an access token and signing a = request that doesn=E2=80=99t include an access token is minimal. = Further, I personally think that the use case for clients who aren=E2=80=99= t going to have any access tokens is going to be exceedingly small, and = so optimizing the protocol for that use case is a big lose for the wider = community.

 =E2=80=94 = Justin

On Dec 11, 2020, at 9:17 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

I= commented previously on Dick's input (in short, I disagree - at least = with the cookie comparison).

I'm not sure I follow your point here. = "access_token" already has its field, the proposal is just reusing it = throughout the protocol (see for instance section 3.2.1) as a fairly = consistent api. The only difference is the meaning of the "key" boolean = parameter (which I would be in favor of renaming to clarify).

The proposed alternative = comes with issues with seem very hard to get around, at least in a = systematic way. Like potential logs of capability URLs that include the = token, which opens the doors to vulnerable = implementations. 

Fabien

On Fri, Dec 11, 2020 at 11:24 AM Warren Parad = <wparad@rhosys.ch> wrote:
For = the part I agree with Dick, but I also dislike the separation of the = "access token" into its own field. If I understand continue correctly, the access_token would only ever be used = with the continue uri, in which case, = having the token in the url is much better than having a separate = parameter which has to be merged with the continue request to auth it. = In my opinion there is no reason to break HATEOAS here, this is one of = the few places where the capability URL makes sense, and given its = limited use and accessibility the concerns are alleviated. Additionally = moving the token back into the uri, avoids the whole problem of naming = and how to treat this token.

Warren Parad
Founder, = CTO
Secure your user data and complete your = authorization architecture. Implement Authress.


On Thu, Dec 10, 2020 at 9:06 PM Dick = Hardt <dick.hardt@gmail.com> wrote:
-1 per all the reasons I laid out in https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6= UEVJN8hkY/
3D""=E1=90=A7

On Thu, Dec = 10, 2020 at 7:52 AM Justin Richer <jricher@mit.edu> wrote:
The editors and chairs would like to confirm consensus on a = current pull request:

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

This pull = request simplifies the continuation response and request by making the = access token mandatory, and it clarifies the responsibilities of the AS = in enforcing the security of the continuation request. Several WG = members expressed specific support for keeping the access token to = enable specific use cases, and there was general support for simplifying = the process from what it currently is in the draft. The editors believe = the pull request represents a solution that meets these goals.

This call is open until = Monday December 14. At that point, the PR will be merged unless the = chairs determine there is not rough consensus for its = inclusion.

Thank= you,

 - = Justin, Aaron, and 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

= --Apple-Mail=_DB2305AE-13B9-49AE-832B-2BB6F6894596-- From nobody Fri Dec 11 09:54:50 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4303A0E26 for ; Fri, 11 Dec 2020 09:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q2OrTZlqPDU for ; Fri, 11 Dec 2020 09:54:40 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6123F3A0E1D for ; Fri, 11 Dec 2020 09:54:35 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id a1so11894628ljq.3 for ; Fri, 11 Dec 2020 09:54: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=/WEpSudFWZlXxymVGHtmUYd0vns2ig3+QQuVJ3cjbzY=; b=Lnxz8vqFAuuDdQrCuWqeU4pAKtUa3u1WHkUxFYufrd6T1cLwp5N1rga/KCCf5SZWfq UqwjzwvAfGiPK9u1Roni9P1XCYTAEwXB/6QW3NKLRUZ2l0BfKpjYSsIHIpKy44XaM8V3 DdlKdkEsE5f2meiGNOe4OCrinYmG8URquckfkhKR7n/1VUeq420kWLeSPU9XBkGvqgmO YnlBoZvfIbDv8sKrHw1Tsddwsc+Hd77dAUjrh3ksAfWhbOaFfGSXa2J53kLphuyaUGkV rmC+OFxwGEy4uMr2RTohlWpfmKKc26NH67ezI9QcA+Ug2Yox8MKI4iMjI4vnAjYIEMMa xORA== 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=/WEpSudFWZlXxymVGHtmUYd0vns2ig3+QQuVJ3cjbzY=; b=nJD+7Zj48nkh0ViPofml3HrFbBiZFzaH1C5vRI67iJ+6CZVRMGd+ML1Kf147Y70KnP INlbmZWGYvRsm2ikVFktsmeSAXz4UMG1Eo+mM9G2XevMHS7MXDu0kRMEXW4dnkCPXYkY +IgyKElb5P10I04RBn84ncInOZKYvmZcqGgeYpZky42noKTfm5J1VytHlCS8tcx6EqcL K/3hU+AxlRHnX2QDhvnDD2puwltPS2jHfOJNOpFEs7pCTOJyvaiQD001FC72BrSlb0NY KADrlEzmetnFXrnaI4+aCH81/0P5ZK442TDwOfEL81mZT2gjkzE1bp0R0S6Qsag8DaqP KB8A== X-Gm-Message-State: AOAM530COfUWjdjTTf0hpVzqwhEQp/SZGD1ri0rNZx6W/XNvnpFQDp5i S9ChyQNqy7KmMhx7Tm9HngMe7ES3tdhN8jOuNaQ= X-Google-Smtp-Source: ABdhPJz4IcFCEBSb/q6KWPO8MIN8O56bQtGJdMRDVRcBO9rdHTo0cDrbPcW7z6jegj8ckd4O4FktqNY6hybSy+FxqZc= X-Received: by 2002:a2e:9654:: with SMTP id z20mr5338050ljh.335.1607709273042; Fri, 11 Dec 2020 09:54:33 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 11 Dec 2020 09:53:56 -0800 Message-ID: To: Justin Richer Cc: Fabien Imbault , Warren Parad , txauth gnap Content-Type: multipart/alternative; boundary="0000000000001f33fc05b633fc35" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 17:54:50 -0000 --0000000000001f33fc05b633fc35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin / Fabien: are your responses as editors, or as individuals? Are you gathering consensus, or arguing your views? Fabien: I don't think you understand how cookies work -- they are not set by the client. I agree with the consistency and clarity goals for client developers -- this proposal violates both. How the client makes the initial request is different from the continue calls. To be consistent, the client would authenticate the same way on all calls. In contrast to calls to the AS, the RS is not handing back an "access_token" to use on subsequent calls. A key-bound access token is an important option when calling an RS -- but bearer tokens have proven to be adequate for many APIs -- so many clients will likely not have to use key-bound access tokens when calling an RS. Not all clients are needed to access an RS -- the client may only be acquiring claims. While a token-based protocol is interesting -- it is not a common pattern -- and a token-based protocol is not the same as one using an access token -- and it is not a common pattern that I have seen -- for the small number of AS that want to be completely distributed and stateless -- they can put it in the URL -- or a new standard mechanism for a token-based protocol can be developed -- or they could use cookies just as web browsers do for maintaining state. I have zero requirement to encapsulate the grant request in a token -- having a URI uniquely identify the request works fine, just as it does with many, many other deployed APIs -- requiring an AS to create a token it does not need so that it conforms with the protocol adds complexity with zero benefit. =E1=90=A7 On Fri, Dec 11, 2020 at 9:07 AM Justin Richer wrote: > Consistency and clarity for client developers is the goal with the > proposed PR. Since the =E2=80=9Ccontinue=E2=80=9D set of functions was re= factored to be an > API, the thought was to treat this API exactly like we=E2=80=99d treat an= external > API hosted at an RS. This pattern would allow the AS to reap the benefits > of a token-based protocol (distributed deployments, better security, and = so > on) as well as making the client developer=E2=80=99s life easier by not m= aking them > do something special just to talk to the AS. > > As Fabien points out, the =E2=80=9Caccess_token=E2=80=9D field is exactly= the same field > as what comes back in a response for a separate API. The semantics of > everything in that field are exactly the same in both places, including t= he > =E2=80=9Ckey=E2=80=9D field. The only difference, right now, is that the = =E2=80=9Ckey=E2=80=9D field is > only allowed to have one value, to indicate it=E2=80=99s bound to the req= uesting > client=E2=80=99s instance key that was used in the initial request. There= =E2=80=99s been > some confusion on that, and so it=E2=80=99s something we might want to ch= ange =E2=80=94 but > that=E2=80=99s a separate issue, and if we use access tokens for continua= tion then > we can solve that problem in a consistent way. > > When the client is continuing, you can think of the key presentation as i= t > =E2=80=9Cauthenticating=E2=80=9D, but I=E2=80=99d argue that you don=E2= =80=99t need to =E2=80=9Cauthenticate=E2=80=9D the > client at this stage: you just need the context of the ongoing request, a= nd > you need to make sure that the caller of that request is the right caller= . > That is, they can present the right set of security material. A key-bound > access token is the perfect map to this function, and it=E2=80=99s someth= ing we > already want as a core artifact. It also has the benefit of allowing > different parts of the AS to communicate via the access token itself > without things getting leaked in the URL. Could we put all that state in > the URL itself? Sure, but then we need to include discussion about how to > protect all of that. Instead, we have an opportunity to avoid problems th= at > we already know exist, instead of repeating them and requiring fixes out = of > the gate. GNAP is our opportunity to do things better than before. > > It=E2=80=99s been argued that a client that isn=E2=80=99t dealing with ac= cess tokens at > all would need to know something =E2=80=9Cnew=E2=80=9D to deal with this = continuation API. > While technically true, the difference between signing a request that > includes an access token and signing a request that doesn=E2=80=99t inclu= de an > access token is minimal. Further, I personally think that the use case fo= r > clients who aren=E2=80=99t going to have any access tokens is going to be > exceedingly small, and so optimizing the protocol for that use case is a > big lose for the wider community. > > =E2=80=94 Justin > > On Dec 11, 2020, at 9:17 AM, Fabien Imbault > wrote: > > Hi, > > I commented previously on Dick's input (in short, I disagree - at least > with the cookie comparison). > > I'm not sure I follow your point here. "access_token" already has its > field, the proposal is just reusing it throughout the protocol (see for > instance section 3.2.1) as a fairly consistent api. The only difference i= s > the meaning of the "key" boolean parameter (which I would be in favor of > renaming to clarify). > > The proposed alternative comes with issues with seem very hard to get > around, at least in a systematic way. Like potential logs of capability > URLs that include the token, which opens the doors to vulnerable > implementations. > > Fabien > > On Fri, Dec 11, 2020 at 11:24 AM Warren Parad wrote: > >> For the part I agree with Dick, but I also dislike the separation of the >> "access token" into its own field. If I understand *continue* correctly, >> the *access_token *would only ever be used with the *continue *uri, in >> which case, having the token in the url is much better than having a >> separate parameter which has to be merged with the continue request to a= uth >> it. In my opinion there is no reason to break HATEOAS here, this is one = of >> the few places where the capability URL makes sense, and given its limit= ed >> use and accessibility the concerns are alleviated. Additionally moving t= he >> token back into the uri, avoids the whole problem of naming and how to >> treat this token. >> >> Warren Parad >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress . >> >> >> On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt wrote: >> >>> -1 per all the reasons I laid out in >>> https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hk= Y/ >>> =E1=90=A7 >>> >>> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer wrote: >>> >>>> The editors and chairs would like to confirm consensus on a current >>>> pull request: >>>> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >>>> >>>> This pull request simplifies the continuation response and request by >>>> making the access token mandatory, and it clarifies the responsibiliti= es of >>>> the AS in enforcing the security of the continuation request. Several = WG >>>> members expressed specific support for keeping the access token to ena= ble >>>> specific use cases, and there was general support for simplifying the >>>> process from what it currently is in the draft. The editors believe th= e >>>> pull request represents a solution that meets these goals. >>>> >>>> This call is open until Monday December 14. At that point, the PR will >>>> be merged unless the chairs determine there is not rough consensus for= its >>>> inclusion. >>>> >>>> Thank you, >>>> >>>> - Justin, Aaron, and 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 > > > --0000000000001f33fc05b633fc35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin / Fabien: are your responses as editors, or as= individuals? Are you gathering consensus, or arguing your views?
=

Fabien: I don't think you understand how cookies wo= rk -- they are not set by the client.

I agree with the = consistency and clarity goals for client developers -- this proposal violat= es both.

How the client makes the initial=C2=A0request i= s different from the continue calls. To be consistent, the client would aut= henticate the same way on all calls.

In contrast t= o calls to the AS, the RS is not handing back an "access_token" t= o use on subsequent calls.

A key-bound access toke= n is an important option when calling an RS -- but bearer tokens have prove= n to be adequate for many APIs -- so many clients will likely not have to u= se key-bound access tokens when calling an RS.

Not= all clients are needed to access an RS -- the client may only be acquiring= claims.

While a token-based protocol is interesti= ng -- it is not a common pattern -- and a token-based=C2=A0protocol is not = the same as one using an access token -- and it is not a common pattern tha= t I have seen -- for the small number of AS that want to be completely dist= ributed and stateless -- they can put it in the URL -- or a new standard me= chanism for a token-based protocol can be developed -- or they could use co= okies just as web browsers do for maintaining state.

I have zero requirement to encapsulate the grant request in a token -- h= aving a URI uniquely identify the request works fine, just as it does with = many, many other deployed APIs -- requiring an AS to create a token it does= not need so that it conforms with the protocol adds complexity with zero b= enefit.

3D""=E1=90=A7

On Fri, Dec 11, = 2020 at 9:07 AM Justin Richer <jriche= r@mit.edu> wrote:
Consistency and clarit= y for client developers is the goal with the proposed PR. Since the =E2=80= =9Ccontinue=E2=80=9D set of functions was refactored to be an API, the thou= ght was to treat this API exactly like we=E2=80=99d treat an external API h= osted at an RS. This pattern would allow the AS to reap the benefits of a t= oken-based protocol (distributed deployments, better security, and so on) a= s well as making the client developer=E2=80=99s life easier by not making t= hem do something special just to talk to the AS.

As Fabi= en points out, the =E2=80=9Caccess_token=E2=80=9D field is exactly the same= field as what comes back in a response for a separate API. The semantics o= f everything in that field are exactly the same in both places, including t= he =E2=80=9Ckey=E2=80=9D field. The only difference, right now, is that the= =E2=80=9Ckey=E2=80=9D field is only allowed to have one value, to indicate= it=E2=80=99s bound to the requesting client=E2=80=99s instance key that wa= s used in the initial request. There=E2=80=99s been some confusion on that,= and so it=E2=80=99s something we might want to change =E2=80=94 but that= =E2=80=99s a separate issue, and if we use access tokens for continuation t= hen we can solve that problem in a consistent way.

When the client is continuing, you can think of the key presentation as it= =E2=80=9Cauthenticating=E2=80=9D, but I=E2=80=99d argue that you don=E2=80= =99t need to =E2=80=9Cauthenticate=E2=80=9D the client at this stage: you j= ust need the context of the ongoing request, and you need to make sure that= the caller of that request is the right caller. That is, they can present = the right set of security material. A key-bound access token is the perfect= map to this function, and it=E2=80=99s something we already want as a core= artifact. It also has the benefit of allowing different parts of the AS to= communicate via the access token itself without things getting leaked in t= he URL. Could we put all that state in the URL itself? Sure, but then we ne= ed to include discussion about how to protect all of that. Instead, we have= an opportunity to avoid problems that we already know exist, instead of re= peating them and requiring fixes out of the gate. GNAP is our opportunity t= o do things better than before.

It=E2=80=99s been ar= gued that a client that isn=E2=80=99t dealing with access tokens at all wou= ld need to know something =E2=80=9Cnew=E2=80=9D to deal with this continuat= ion API. While technically true, the difference between signing a request t= hat includes an access token and signing a request that doesn=E2=80=99t inc= lude an access token is minimal. Further, I personally think that the use c= ase for clients who aren=E2=80=99t going to have any access tokens is going= to be exceedingly small, and so optimizing the protocol for that use case = is a big lose for the wider community.

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

On Dec 11, 2020,= at 9:17 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi,=C2=A0

I commented pre= viously on Dick's input (in short, I disagree - at least with the=C2=A0= cookie comparison).

I'm not sure I follow your= point here. "access_token" already has its field, the proposal i= s just reusing it throughout the protocol (see for instance section 3.2.1) = as a fairly consistent api. The only difference is the meaning of the "= ;key" boolean parameter (which I would be in favor of renaming to clar= ify).

The proposed alternative comes with issues w= ith seem very hard to get around, at least in a systematic way. Like potent= ial logs of capability URLs that include the token, which opens the doors t= o vulnerable implementations.=C2=A0

Fabien

On Fri, Dec 11, 2020 at 11:24 AM Warren Parad= <wparad@rhosys.ch= > wrote:
=
For the part I agree with Dick, but I also dislike the sep= aration of the "access token" into its own field. If I understand= =C2=A0continue=C2=A0correctly, the=C2=A0access_token= =C2=A0would only ever be used with the=C2=A0<= b>continue=C2=A0uri, in which case, having the token in th= e url is much better than having a separate parameter which has to be merge= d with the continue request to auth it. In my opinion there is no reason to= break HATEOAS here, this is one of the few places where the capability URL= makes sense, and given its limited use and accessibility the concerns are = alleviated. Additionally moving the token back into the uri, avoids the who= le problem of naming and how to treat this token.

<= tbody>
Warren Parad
Founder, CTO
Secure your user data and c= omplete your authorization architecture. Implement=C2=A0Authre= ss.

<= /div>

On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
<= /div>
-1 = per all the reasons I laid out in=C2=A0https:/= /mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/
3D""=E1=90=A7

On Thu, Dec 10, 2020 at 7:52 AM Justin Richer= <jricher@mit.edu> wrote:
The editors and chairs would like to confirm consensus on a current pull= request:


This pull request= simplifies the continuation response and request by making the access toke= n mandatory, and it clarifies the responsibilities of the AS in enforcing t= he security of the continuation request. Several WG members expressed speci= fic support for keeping the access token to enable specific use cases, and = there was general support for simplifying the process from what it currentl= y is in the draft. The editors believe the pull request represents a soluti= on that meets these goals.

This call is open until= Monday December 14. At that point, the PR will be merged unless the chairs= determine there is not rough consensus for its inclusion.

Thank you,

=C2=A0- Justin, Aaron, and Fab= ien
--=C2=A0
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--=C2=A0
TXAuth mailing list
TXAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/txauth
--=C2=A0
TXAuth mailing list
TXAuth@ietf.org
https://www.ie= tf.org/mailman/listinfo/txauth

--0000000000001f33fc05b633fc35-- From nobody Fri Dec 11 09:56:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF333A0D47 for ; Fri, 11 Dec 2020 09:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdaIODDeCVQn for ; Fri, 11 Dec 2020 09:56:39 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728F13A0D40 for ; Fri, 11 Dec 2020 09:56:38 -0800 (PST) Received: from [192.168.1.11] ([90.91.135.71]) by mwinf5d60 with ME id 35wX2400c1Ybo4i035wXqU; Fri, 11 Dec 2020 18:56:33 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 11 Dec 2020 18:56:33 +0100 X-ME-IP: 90.91.135.71 To: Fabien Imbault Cc: GNAP Mailing List References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> <21cf7c30-c42a-f29c-a407-7badde5c0151@free.fr> From: Denis Message-ID: Date: Fri, 11 Dec 2020 18:56:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------378E461D21753F9DF42D159A" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] RS-Token Introspection or RC-Token Introspection 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, 11 Dec 2020 17:56:42 -0000 This is a multi-part message in MIME format. --------------378E461D21753F9DF42D159A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, > Hi Denis, > > Please note that the token introspection is not a new idea, it's > already present in OAuth2 world (rfc 7662), and allows the RS to > verify the access token. I am pretty aware that token introspection is already present in the OAuth2 world (rfc 7662). :-) In important point : RFC 7662 states "the contents of tokens are opaque to clients". The text does _not_ state : "the contents of tokens are opaque to both clients and Resource Servers (RSs). > In the current version of GNAP, there is also section 6 that > introduces management endpoints, which could potentially be extended > in a similar way (currently this is not specified, the management > endpoint is here for rotation/revocation). Then the client could > require more information on what is included in the opaque token, but > of course, this relies on the assumption that the client trusts the > AS. There is also the discussion on the "resource" description in the > response, that may provide a simpler scheme > (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141 > ). > But if we assume the AS may be malevolent (which is more likely if the > AS becomes a less central point, at least for some implementations), > then indeed receiving opaque tokens wouldn't provide all the > guarantees, as it may lie on what is really in the token (too many > claims for instance). > More specifically, while I recon there might be a risk which we'd > rather not have, I don't really think an opaque token is really an > unmanageable issue with privacy. > Suppose someone adds a field in a JWT, most likely you'll be able to > detect that. RFC 7662 has been made available primarily for "lazy" RSs. :-) Let us consider a case where the contents of access tokens are opaque to both RCs and RSs. Let us suppose that opaque access tokens contains only a temporary handle to the set of claims related to the end-user, e.g. a 128 bits handle. Neither the RC, nor the RS would be able to understand it and the RS would be forced to call back the AS. Not only this call back will be bad in terms of the user's privacy because the AS will be able to know exactly when the access token has been used by the end-user but it would be impossible to detect it to prevent some damage on the RS side. We cannot assume that all future ASs in the world, while still providing the requested claims, will never deliver more attributes than the ones requested by the RC and thus allow RSs (and possibly other servers) link their users. > > But suppose we go for non opaque tokens, then we'd need a way of > describing its format. Which might limit a bit the use cases if we're > not careful. In OAuth 2.0, it has been possible to describe a token format (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens). I don't believe it would a "mission impossible" in this WG to describe a GNAP format for access tokens. The IETF is supposed to standardize protocols at the bit level and this has made its success. Denis > > I'd be interested to know what others think, since it is diverging > quite a bit from the OAuth2 world (not a bad thing in itself but still). > > Fabien > > On Fri, Dec 11, 2020 at 12:04 PM Denis > wrote: > > Hi Fabien, > > This is a response only to the point 7 from the "Quick review of > draft-ietf-gnap-core-protocol-00". > The full original text with your comments is copied after my reply. > > In order to allow the RC to understand the content of an opaque > token, you are proposing to support a Token Introspection query > from the RC to the AS. > This does not solve the concerns of a RC that wants to make sure > that the access token does not contain claims that have not been > requested. > > Let us illustrate the case by using an example: > > The RC asks to the AS to deliver an access token that contains an > identifier only unique to the RS. > In reality, the AS delivers an access token that does contain an > identifier only unique to the RS > but in addition a globally unique identifier. Since the access > token is supposed to be opaque to the RC, > the RC calls the AS to perform a Token Introspection operation. In > its response, the AS presents an identifier > that is indeed only unique to the RS but the AS voluntarily *omits > *to present the globally unique identifier to the RC. > > In the same way, if Token Introspection is supported by a RS, that > does not provide confidence to the end-user or to the RC. > > Let us illustrate the case by using another example: > > The AS delivers to the RC an access token that only contains an > identifier unique to the RS. Since the access token > is supposed to be opaque to the RS, the RS calls the AS to perform > a Token Introspection operation. In its response, > the AS presents an identifier that is indeed only unique to the RS > but the AS voluntarily *adds *a globally unique identifier. > > _Conclusion_: In both cases, a globally unique identifier will be > used by the RS without the RC or the end-user knowing it. >                       Opaque tokens are in contradiction with the > end-user's privacy. > > For end-users caring about their privacy (or for systems willing > to protect the user's privacy), access tokens should not be > considered > to be opaque to RCs, nor to RSs, and ASs should not support Token > Introspection, whether it is RS-Token Introspection or RC-Token > Introspection. > > Denis > > >>> 7.The content and the format of access tokens shall >>> not be considered to be opaque to the RC so that the >>> RC can inspect it. >>>     This is a matter of confidence to make sure for >>> the RC (and for the user) that no "extra" >>> information has been included by the AS into the >>> access token. >>> >>> [FI] This might go a bit further than the GNAP's mandate >>> (especially if it becomes a mandatory requirement). But >>> supposing we support non-opaque tokens, >>> does it preclude supporting opaque tokens? It's just a >>> different trust model, which makes sense if people agree >>> with your premises (previous items), >>> but that are less relevant if people still consider the AS >>> as the central piece. Also one great thing with opaque >>> tokens is that it makes the system easier to upgrade >>> (you don't really care about what a token is). >> >> [Denis] Privacy is not more relevant for an AS-centric model >> than for a RS-centric model. In particular, a RC should be >> able to verify which kind of end-user identifier claim >> has been incorporated into the access token by the AS, in >> particular whether it is globally unique, unique to the AS >> only, unique to the RS only or ephemeral (valid for >> that RS during a session with the AS). >> >> [FI2] ok, see discussion on whether tokens should be opaque or not. >> >> I suppose that the use of structured access tokens should be >> recommended. This means,in particular, that from the very >> beginning, we should incorporate a version number >> inside each access token. >> >> >>> One alternative way would be to allow RS call to AS for >>> verification (including revocation status) and include a >>> checksum. >> >> [Denis]  The RC, i.e. not the RS, should be able to perform >> such verification before presenting the access token to the >> RS. So this alternative way would not work. >> >> [FI2] then there could be a similar API for the client (cf >> discussion on similarities between introspection/management APIs). >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --------------378E461D21753F9DF42D159A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Fabien,

Hi Denis, 

Please note that the token introspection is not a new idea, it's already present in OAuth2 world (rfc 7662), and allows the RS to verify the access token.

I am pretty aware that token introspection is already present in the OAuth2 world (rfc 7662). :-)

In important point : RFC 7662 states "the contents of tokens are opaque to clients".
The text does not state : "the contents of tokens are opaque to both clients and Resource Servers (RSs).


In the current version of GNAP, there is also section 6 that introduces management endpoints, which could potentially be extended in a similar way (currently this is not specified, the management endpoint is here for rotation/revocation). Then the client could require more information on what is included in the opaque token, but of course, this relies on the assumption that the client trusts the AS. There is also the discussion on the "resource" description in the response, that may provide a simpler scheme (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141). 
 
But if we assume the AS may be malevolent (which is more likely if the AS becomes a less central point, at least for some implementations),
then indeed receiving opaque tokens wouldn't provide all the guarantees, as it may lie on what is really in the token (too many claims for instance).

More specifically, while I recon there might be a risk which we'd rather not have, I don't really think an opaque token is really an unmanageable issue with privacy.
Suppose someone adds a field in a JWT, most likely you'll be able to detect that.

RFC 7662 has been made available primarily for "lazy" RSs. :-)

Let us consider a case where the contents of access tokens are opaque to both RCs and RSs.

Let us suppose that opaque access tokens contains only a temporary handle to the set of claims related to the end-user, e.g. a 128 bits handle.

Neither the RC, nor the RS would be able to understand it and the RS would be forced to call back the AS.
Not only this call back will be bad in terms of the user's privacy because the AS will be able to know exactly when the access token has been used
by the end-user but it would be impossible to detect it to prevent some damage on the RS side.

We cannot assume that all future ASs in the world, while still providing the requested claims, will never deliver more attributes than the ones requested
by the RC and thus allow RSs (and possibly other servers) link their users.

But suppose we go for non opaque tokens, then we'd need a way of describing its format. Which might limit a bit the use cases if we're not careful.

In OAuth 2.0, it has been possible to describe a token format (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens).
I don't believe it would a "mission impossible" in this WG to describe a GNAP format for access tokens.

The IETF is supposed to standardize protocols at the bit level and this has made its success.

Denis


I'd be interested to know what others think, since it is diverging quite a bit from the OAuth2 world (not a bad thing in itself but still). 

Fabien

On Fri, Dec 11, 2020 at 12:04 PM Denis <denis.ietf@free.fr> wrote:
Hi Fabien,

This is a response only to the point 7 from the "Quick review of draft-ietf-gnap-core-protocol-00".
The full original text with your comments is copied after my reply.

In order to allow the RC to understand the content of an opaque token, you are proposing to support a Token Introspection query from the RC to the AS.
This does not solve the concerns of a RC that wants to make sure that the access token does not contain claims that have not been requested.

Let us illustrate the case by using an example:

The RC asks to the AS to deliver an access token that contains an identifier only unique to the RS.
In reality, the AS delivers an access token that does contain an identifier only unique to the RS
but in addition a globally unique identifier. Since the access token is supposed to be opaque to the RC,
the RC calls the AS to perform a Token Introspection operation. In its response, the AS presents an identifier
that is indeed only unique to the RS but the AS voluntarily omits to present the globally unique identifier to the RC.

In the same way, if Token Introspection is supported by a RS, that does not provide confidence to the end-user or to the RC.

Let us illustrate the case by using another example:

The AS delivers to the RC an access token that only contains an identifier unique to the RS. Since the access token
is supposed to be opaque to the RS, the RS calls the AS to perform a Token Introspection operation. In its response,
the AS presents an identifier that is indeed only unique to the RS but the AS voluntarily adds a globally unique identifier.

Conclusion: In both cases, a globally unique identifier will be used by the RS without the RC or the end-user knowing it.
                      Opaque tokens are in contradiction with the end-user's privacy.

For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
to be opaque to RCs, nor to RSs, and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

Denis


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
    This is a matter of confidence to make sure for the RC (and for the user) that no "extra" information has been included by the AS into the access token.

[FI] This might go a bit further than the GNAP's mandate (especially if it becomes a mandatory requirement). But supposing we support non-opaque tokens,
does it preclude supporting opaque tokens? It's just a different trust model, which makes sense if people agree with your premises (previous items),
but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade
(you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for
that RS during a session with the AS).

[FI2] ok, see discussion on whether tokens should be opaque or not.

I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number
inside each access token.


One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum.

[Denis]  The RC, i.e. not the RS, should be able to perform such verification before presenting the access token to the RS. So this alternative way would not work.

[FI2] then there could be a similar API for the client (cf discussion on similarities between introspection/management APIs).


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


--------------378E461D21753F9DF42D159A-- From nobody Fri Dec 11 09:58:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619CF3A0D66 for ; Fri, 11 Dec 2020 09:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWWk70EAMbEM for ; Fri, 11 Dec 2020 09:58:16 -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 AB8CD3A0D47 for ; Fri, 11 Dec 2020 09:58:16 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id t8so10330589iov.8 for ; Fri, 11 Dec 2020 09:58:16 -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=lp4OyvB9fF9czJBBRuj/b8VjUtDGw6OILepkLF3GnUI=; b=jlJWzjXWcbz3S8H5eCZtrP0e5+jTLDvcSOO5Tk4y5Pm+Lkn9kjgDlEvmBGwxPDdCtv K16tt5oTZy0+1DIBPSPm1MedWRwCjmVP7Z61hG8CKfKoFsFIKOg8f37Ertu3LyDez41s ti3QNUXrCtvACOLmZXUiMNAMlzhRBnBJAJmFxoIk5nuADQqdIa+r8BUZ755ggv7+3ol9 bxibXti8oSZX89u/Ir62IM89qVCRkXJiQ17y/UnescWN/jHf5sdPLq5BSsv/6h2kqa5g kseaVqw1jQbv1p0Xf6Tyhwxcib0UstmG+UX/cCWD6TsbYaC/pU6U7w0oFJKRBaSoQxFx P5yg== 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=lp4OyvB9fF9czJBBRuj/b8VjUtDGw6OILepkLF3GnUI=; b=QvIiFPejB/RzN/ooz3jwDyNlag5y9ac1bOS6SvYiJe2iI+4F3vDj7mfBC7dyZegdiv L7o9BUjtjcOdy3mBAw+kcHQkw6DimKTYTXLJ/4wLG1p7cqpXzv0EUbxEcv0HemJ4pQ0r 1xFabUUptxerOix5ggWKcFbtVNp1e/WNtdMGQUtsbZBljat5Ezj2qkRn0a0sdpMJx4Vj idfILubJSD86G6v0GbKZba3rXZxzMuQtZLQuyit+PTxuoSrn/uJhcVg8YcvFQw6grg7s rqVdOgLSxbjWnZ5e5lsa4rrVTo1oVfh3l57utrVD7ICVhOLc4L8LqhATpJMQOLPc++er vT7A== X-Gm-Message-State: AOAM532EDGVLaRM45GBl7m9eO332dZoK2toGl8LTnxXNxeAtlPDc1kI3 Mrbt4u6WVkX1jHqQ5JRxyIewwxxhJYk/jC/eumw= X-Google-Smtp-Source: ABdhPJzPoGNpSPv2v4gsppRPp6JlfshQ4QqHO+BYgMA6QtIlJOSB+YGIYm+yqtiEk1iGxVGlXfMWLF3CtjQOckNq6eg= X-Received: by 2002:a5e:a815:: with SMTP id c21mr15779942ioa.141.1607709495956; Fri, 11 Dec 2020 09:58:15 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> In-Reply-To: From: Fabien Imbault Date: Fri, 11 Dec 2020 18:58:04 +0100 Message-ID: To: Dick Hardt Cc: Justin Richer , Warren Parad , txauth gnap Content-Type: multipart/alternative; boundary="00000000000068993705b634090b" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 17:58:19 -0000 --00000000000068993705b634090b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That was as an individual. Fabien ps: I'm pretty sure I understand how cookies work, but that's beyond the point. On Fri, Dec 11, 2020 at 6:54 PM Dick Hardt wrote: > Justin / Fabien: are your responses as editors, or as individuals? Are yo= u > gathering consensus, or arguing your views? > > Fabien: I don't think you understand how cookies work -- they are not set > by the client. > > I agree with the consistency and clarity goals for client developers -- > this proposal violates both. > > How the client makes the initial request is different from the continue > calls. To be consistent, the client would authenticate the same way on al= l > calls. > > In contrast to calls to the AS, the RS is not handing back an > "access_token" to use on subsequent calls. > > A key-bound access token is an important option when calling an RS -- but > bearer tokens have proven to be adequate for many APIs -- so many clients > will likely not have to use key-bound access tokens when calling an RS. > > Not all clients are needed to access an RS -- the client may only be > acquiring claims. > > While a token-based protocol is interesting -- it is not a common pattern > -- and a token-based protocol is not the same as one using an access toke= n > -- and it is not a common pattern that I have seen -- for the small numbe= r > of AS that want to be completely distributed and stateless -- they can pu= t > it in the URL -- or a new standard mechanism for a token-based protocol c= an > be developed -- or they could use cookies just as web browsers do for > maintaining state. > > I have zero requirement to encapsulate the grant request in a token -- > having a URI uniquely identify the request works fine, just as it does wi= th > many, many other deployed APIs -- requiring an AS to create a token it do= es > not need so that it conforms with the protocol adds complexity with zero > benefit. > > =E1=90=A7 > > On Fri, Dec 11, 2020 at 9:07 AM Justin Richer wrote: > >> Consistency and clarity for client developers is the goal with the >> proposed PR. Since the =E2=80=9Ccontinue=E2=80=9D set of functions was r= efactored to be an >> API, the thought was to treat this API exactly like we=E2=80=99d treat a= n external >> API hosted at an RS. This pattern would allow the AS to reap the benefit= s >> of a token-based protocol (distributed deployments, better security, and= so >> on) as well as making the client developer=E2=80=99s life easier by not = making them >> do something special just to talk to the AS. >> >> As Fabien points out, the =E2=80=9Caccess_token=E2=80=9D field is exactl= y the same field >> as what comes back in a response for a separate API. The semantics of >> everything in that field are exactly the same in both places, including = the >> =E2=80=9Ckey=E2=80=9D field. The only difference, right now, is that the= =E2=80=9Ckey=E2=80=9D field is >> only allowed to have one value, to indicate it=E2=80=99s bound to the re= questing >> client=E2=80=99s instance key that was used in the initial request. Ther= e=E2=80=99s been >> some confusion on that, and so it=E2=80=99s something we might want to c= hange =E2=80=94 but >> that=E2=80=99s a separate issue, and if we use access tokens for continu= ation then >> we can solve that problem in a consistent way. >> >> When the client is continuing, you can think of the key presentation as >> it =E2=80=9Cauthenticating=E2=80=9D, but I=E2=80=99d argue that you don= =E2=80=99t need to =E2=80=9Cauthenticate=E2=80=9D >> the client at this stage: you just need the context of the ongoing reque= st, >> and you need to make sure that the caller of that request is the right >> caller. That is, they can present the right set of security material. A >> key-bound access token is the perfect map to this function, and it=E2=80= =99s >> something we already want as a core artifact. It also has the benefit of >> allowing different parts of the AS to communicate via the access token >> itself without things getting leaked in the URL. Could we put all that >> state in the URL itself? Sure, but then we need to include discussion ab= out >> how to protect all of that. Instead, we have an opportunity to avoid >> problems that we already know exist, instead of repeating them and >> requiring fixes out of the gate. GNAP is our opportunity to do things >> better than before. >> >> It=E2=80=99s been argued that a client that isn=E2=80=99t dealing with a= ccess tokens at >> all would need to know something =E2=80=9Cnew=E2=80=9D to deal with this= continuation API. >> While technically true, the difference between signing a request that >> includes an access token and signing a request that doesn=E2=80=99t incl= ude an >> access token is minimal. Further, I personally think that the use case f= or >> clients who aren=E2=80=99t going to have any access tokens is going to b= e >> exceedingly small, and so optimizing the protocol for that use case is a >> big lose for the wider community. >> >> =E2=80=94 Justin >> >> On Dec 11, 2020, at 9:17 AM, Fabien Imbault >> wrote: >> >> Hi, >> >> I commented previously on Dick's input (in short, I disagree - at least >> with the cookie comparison). >> >> I'm not sure I follow your point here. "access_token" already has its >> field, the proposal is just reusing it throughout the protocol (see for >> instance section 3.2.1) as a fairly consistent api. The only difference = is >> the meaning of the "key" boolean parameter (which I would be in favor of >> renaming to clarify). >> >> The proposed alternative comes with issues with seem very hard to get >> around, at least in a systematic way. Like potential logs of capability >> URLs that include the token, which opens the doors to vulnerable >> implementations. >> >> Fabien >> >> On Fri, Dec 11, 2020 at 11:24 AM Warren Parad wrote: >> >>> For the part I agree with Dick, but I also dislike the separation of th= e >>> "access token" into its own field. If I understand *continue* correctly= , >>> the *access_token *would only ever be used with the *continue *uri, in >>> which case, having the token in the url is much better than having a >>> separate parameter which has to be merged with the continue request to = auth >>> it. In my opinion there is no reason to break HATEOAS here, this is one= of >>> the few places where the capability URL makes sense, and given its limi= ted >>> use and accessibility the concerns are alleviated. Additionally moving = the >>> token back into the uri, avoids the whole problem of naming and how to >>> treat this token. >>> >>> Warren Parad >>> Founder, CTO >>> Secure your user data and complete your authorization architecture. >>> Implement Authress . >>> >>> >>> On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt wrote= : >>> >>>> -1 per all the reasons I laid out in >>>> https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8h= kY/ >>>> =E1=90=A7 >>>> >>>> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer wrote: >>>> >>>>> The editors and chairs would like to confirm consensus on a current >>>>> pull request: >>>>> >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >>>>> >>>>> This pull request simplifies the continuation response and request by >>>>> making the access token mandatory, and it clarifies the responsibilit= ies of >>>>> the AS in enforcing the security of the continuation request. Several= WG >>>>> members expressed specific support for keeping the access token to en= able >>>>> specific use cases, and there was general support for simplifying the >>>>> process from what it currently is in the draft. The editors believe t= he >>>>> pull request represents a solution that meets these goals. >>>>> >>>>> This call is open until Monday December 14. At that point, the PR wil= l >>>>> be merged unless the chairs determine there is not rough consensus fo= r its >>>>> inclusion. >>>>> >>>>> Thank you, >>>>> >>>>> - Justin, Aaron, and 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 >> >> >> --00000000000068993705b634090b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That was as an individual.=C2=A0

F= abien

ps:=C2=A0I'm pretty sure I understand ho= w cookies work, but that's beyond the point.

= =C2=A0

On Fri, Dec 11, 2020 at 6:54 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=
Jus= tin / Fabien: are your responses as editors, or as individuals? Are you gat= hering consensus, or arguing your views?

Fabie= n: I don't think you understand how cookies work -- they are not set by= the client.

I agree with the consistency and clarity g= oals for client developers -- this proposal violates both.

How the client makes the initial=C2=A0request is different from the cont= inue calls. To be consistent, the client would authenticate the same way on= all calls.

In contrast to calls to the AS, the RS= is not handing back an "access_token" to use on subsequent calls= .

A key-bound access token is an important option = when calling an RS -- but bearer tokens have proven to be adequate for many= APIs -- so many clients will likely not have to use key-bound access token= s when calling an RS.

Not all clients are needed t= o access an RS -- the client may only be acquiring claims.

While a token-based protocol is interesting -- it is not a common = pattern -- and a token-based=C2=A0protocol is not the same as one using an = access token -- and it is not a common pattern that I have seen -- for the = small number of AS that want to be completely distributed and stateless -- = they can put it in the URL -- or a new standard mechanism for a token-based= protocol can be developed -- or they could use cookies just as web browser= s do for maintaining state.

I have zero requiremen= t to encapsulate the grant request in a token -- having a URI uniquely iden= tify the request works fine, just as it does with many, many other deployed= APIs -- requiring an AS to create a token it does not need so that it conf= orms with the protocol adds complexity with zero benefit.

=3D""=E1=90=A7

On Fri, Dec 11, 2020 at 9:07 AM J= ustin Richer <jrich= er@mit.edu> wrote:
Consistency and clarity for client developers is the goal w= ith the proposed PR. Since the =E2=80=9Ccontinue=E2=80=9D set of functions = was refactored to be an API, the thought was to treat this API exactly like= we=E2=80=99d treat an external API hosted at an RS. This pattern would all= ow the AS to reap the benefits of a token-based protocol (distributed deplo= yments, better security, and so on) as well as making the client developer= =E2=80=99s life easier by not making them do something special just to talk= to the AS.

As Fabien points out, the =E2=80=9Caccess_to= ken=E2=80=9D field is exactly the same field as what comes back in a respon= se for a separate API. The semantics of everything in that field are exactl= y the same in both places, including the =E2=80=9Ckey=E2=80=9D field. The o= nly difference, right now, is that the =E2=80=9Ckey=E2=80=9D field is only = allowed to have one value, to indicate it=E2=80=99s bound to the requesting= client=E2=80=99s instance key that was used in the initial request. There= =E2=80=99s been some confusion on that, and so it=E2=80=99s something we mi= ght want to change =E2=80=94 but that=E2=80=99s a separate issue, and if we= use access tokens for continuation then we can solve that problem in a con= sistent way.

When the client is continuing, you ca= n think of the key presentation as it =E2=80=9Cauthenticating=E2=80=9D, but= I=E2=80=99d argue that you don=E2=80=99t need to =E2=80=9Cauthenticate=E2= =80=9D the client at this stage: you just need the context of the ongoing r= equest, and you need to make sure that the caller of that request is the ri= ght caller. That is, they can present the right set of security material. A= key-bound access token is the perfect map to this function, and it=E2=80= =99s something we already want as a core artifact. It also has the benefit = of allowing different parts of the AS to communicate via the access token i= tself without things getting leaked in the URL. Could we put all that state= in the URL itself? Sure, but then we need to include discussion about how = to protect all of that. Instead, we have an opportunity to avoid problems t= hat we already know exist, instead of repeating them and requiring fixes ou= t of the gate. GNAP is our opportunity to do things better than before.
=

It=E2=80=99s been argued that a client that isn=E2=80= =99t dealing with access tokens at all would need to know something =E2=80= =9Cnew=E2=80=9D to deal with this continuation API. While technically true,= the difference between signing a request that includes an access token and= signing a request that doesn=E2=80=99t include an access token is minimal.= Further, I personally think that the use case for clients who aren=E2=80= =99t going to have any access tokens is going to be exceedingly small, and = so optimizing the protocol for that use case is a big lose for the wider co= mmunity.

=C2=A0=E2=80=94 Justin

On Dec 11, 2020, at 9:17 AM, Fabien Imbault <= fabien.imbaul= t@gmail.com> wrote:

H= i,=C2=A0

I commented previously on Dick's input (in = short, I disagree - at least with the=C2=A0cookie comparison).
I'm not sure I follow your point here. "access_token&= quot; already has its field, the proposal is just reusing it throughout the= protocol (see for instance section 3.2.1) as a fairly consistent api. The = only difference is the meaning of the "key" boolean parameter (wh= ich I would be in favor of renaming to clarify).

T= he proposed alternative comes with issues with seem very hard to get around= , at least in a systematic way. Like potential logs of capability URLs that= include the token, which opens the doors to vulnerable implementations.=C2= =A0

Fabien

On= Fri, Dec 11, 2020 at 11:24 AM Warren Parad <wparad@rhosys.ch> wrote:
For the part I = agree with Dick, but I also dislike the separation of the "access toke= n" into its own field. If I understand=C2=A0continue=C2=A0corre= ctly, the=C2=A0access_token=C2=A0would onl= y ever be used with the=C2=A0continue=C2=A0uri, in which case, having the token in the url is much better than having= a separate parameter which has to be merged with the continue request to a= uth it. In my opinion there is no reason to break HATEOAS here, this is one= of the few places where the capability URL makes sense, and given its limi= ted use and accessibility the concerns are alleviated. Additionally moving = the token back into the uri, avoids the whole problem of naming and how to = treat this token.

<= td style=3D"border-width:1pt;border-style:solid;border-color:rgb(255,255,25= 5) rgb(204,204,204) rgb(255,255,255) rgb(255,255,255);vertical-align:top;pa= dding:5pt;overflow:hidden">
=
Warren Parad
F= ounder, CTO
Secure your user data and complete your authorization archi= tecture. Implement=C2=A0Authress.


On Thu, Dec 10, 2020 at 9:0= 6 PM Dick Hardt <dick.hardt@gmail.com> wrote:
3D""=E1=90=A7
On = Thu, Dec 10, 2020 at 7:52 AM Justin Richer <jricher@mit.edu> wrote:
The editors and chairs would l= ike to confirm consensus on a current pull request:


This pull request simplifies the continuation res= ponse and request by making the access token mandatory, and it clarifies th= e responsibilities of the AS in enforcing the security of the continuation = request. Several WG members expressed specific support for keeping the acce= ss token to enable specific use cases, and there was general support for si= mplifying the process from what it currently is in the draft. The editors b= elieve the pull request represents a solution that meets these goals.
=

This call is open until Monday December 14. At that poi= nt, the PR will be merged unless the chairs determine there is not rough co= nsensus for its inclusion.

Thank you,
=C2=A0- Justin, Aaron, and Fabien
--=C2=A0
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/txauth
--=C2=A0
TXA= uth mailing list
TX= Auth@ietf.org
https://www.ietf.org/mailman/listin= fo/txauth
--=C2=A0
TXAuth mailing= list
TXAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/txauth

= --00000000000068993705b634090b-- From nobody Fri Dec 11 09:58:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671883A0D47 for ; Fri, 11 Dec 2020 09:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, 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 JhAu9csBOP-j for ; Fri, 11 Dec 2020 09:58:39 -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 EAE903A0D40 for ; Fri, 11 Dec 2020 09:58:38 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BBHwaNA014793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 12:58:36 -0500 From: Justin Richer Message-Id: <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_580D64E7-F73B-4B1C-B109-D7112C2ADAC9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 11 Dec 2020 12:58:36 -0500 In-Reply-To: Cc: txauth gnap To: Dick Hardt References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 17:58:41 -0000 --Apple-Mail=_580D64E7-F73B-4B1C-B109-D7112C2ADAC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Others had already responded to this previous thread, but I wanted to = add a couple points to clarify some things. > 3) What the client has to do with the "access token" is not the same = as access tokens for an RS. The client gets a new "access token" for = each grant request, and for each API call to the AS, and the client = learns it can not make any more API calls for that specific request when = it does not get an "access token" back. This is a completely different = design pattern than calling an RS API with an access token, and is a new = design pattern for calling APIs. This adds complexity to the client that = it would not normally have, and I don't think GNAP is the right place to = start a new design pattern. >=20 I=E2=80=99m not sure what you mean by these being different =E2=80=94 = the whole point of the design is that the client would be doing the same = thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical. Rotation of the access token and artifacts for ongoing continuation = responses is a separate issue to be discussed: = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 And for what it=E2=80=99s worth, GNAP is absolutely the right place to = have new designs =E2=80=94 not that this is one. > 4) Clients that only want claims from the AS and no access tokens will = be required to support an API calling mechanism they would not have to = support otherwise.=20 Correct, but the delta between the calls a client would make with and = without an access token is vanishingly small. The client has to sign the = initial request in some fashion, and it will sign the continuation = request in the same exact fashion, but now include an access token in = that request.=20 Clients making a request to an AS and not getting an access token is a = new design pattern. I think it has value and should be included, but = OAuth today shows us the immense value of getting access tokens for = calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern. >=20 > 5) If the AS does not provide an "access token", there is no mechanism = for a client to delete the request, as the client is not allowed to make = a call without an "access token". More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D = field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. >=20 > 6) There is no standard identifier for the request. Debugging and = auditing are hampered by the client and AS having no standard way to = identifying a request. While one AS may provide a unique URL for each = grant request, another AS may use a persistent "access token" to = identify the grant request, and other ASs may issue a new "access token" = on each API call, providing no persistent identifier for the request. Debugging and auditing this kind of thing are functions of the AS. How = is interoperability harmed by different ASs having different methods to = identify their internal data elements? The client doesn=E2=80=99t need = any knowledge of the AS=E2=80=99s identifiers, it just needs to know the = next steps for continuing the negotiation. I do agree that there=E2=80=99s a potential use for a consistent = identifier, for things like =E2=80=9Cextending a grant request=E2=80=9D, = and we need to look at that separately as it doesn=E2=80=99t need to be = exposed to the core protocol for most use cases. =E2=80=94 Justin > On Dec 10, 2020, at 3:05 PM, Dick Hardt wrote: >=20 > -1 per all the reasons I laid out in = https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ = > =E1=90=A7 >=20 > On Thu, Dec 10, 2020 at 7:52 AM Justin Richer > wrote: > The editors and chairs would like to confirm consensus on a current = pull request: >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 = >=20 > This pull request simplifies the continuation response and request by = making the access token mandatory, and it clarifies the responsibilities = of the AS in enforcing the security of the continuation request. Several = WG members expressed specific support for keeping the access token to = enable specific use cases, and there was general support for simplifying = the process from what it currently is in the draft. The editors believe = the pull request represents a solution that meets these goals. >=20 > This call is open until Monday December 14. At that point, the PR will = be merged unless the chairs determine there is not rough consensus for = its inclusion. >=20 > Thank you, >=20 > - Justin, Aaron, and Fabien > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_580D64E7-F73B-4B1C-B109-D7112C2ADAC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Others had already responded to this previous thread, but I = wanted to add a couple points to clarify some things.

3) What = the client has to do with the "access token" is not the same as access = tokens for an RS. The client gets a new "access token" for each grant = request, and for each API call to the AS, and the client learns it can = not make any more API calls for that specific request when it does not = get an "access token" back. This is a completely different design = pattern than calling an RS API with an access token, and is a new = design pattern for calling APIs. This adds complexity to the client that = it would not normally have, and I don't think GNAP is the right place to = start a new design pattern.


I=E2=80=99m not sure what you mean by these being different = =E2=80=94 the whole point of the design is that the client would be = doing the same thing with the access token at the AS that it does with = the RS by re-using the access token structure. Can you please describe = what the differences are, apart from the rotation? Presentation of the = token and signing of the message are identical.

Rotation of the access token and = artifacts for ongoing continuation responses is a separate issue to be = discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87

And for what = it=E2=80=99s worth, GNAP is absolutely the right place to have new = designs =E2=80=94 not that this is one.

4) Clients that only want = claims from the AS and no access tokens will be required to support an = API calling mechanism they would not have to support = otherwise. 

Correct, but the delta between the = calls a client would make with and without an access token is = vanishingly small. The client has to sign the initial request in some = fashion, and it will sign the continuation request in the same exact = fashion, but now include an access token in that = request. 

Clients making a request to an AS and not getting an access = token is a new design pattern. I think it has value and should be = included, but OAuth today shows us the immense value of getting access = tokens for calling APIs, and so we shouldn=E2=80=99t optimize away from = that pattern.


5) If = the AS does not provide an "access token", there is no mechanism for a = client to delete the request, as the client is not allowed to make a = call without an "access token".

More properly, if the AS does not = provide a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2=80=99t = delete the request =E2=80=94 and yes, that=E2=80=99s intentional. The AS = is telling this client instance that it can=E2=80=99t do anything else = with this ongoing request. If the AS wants to allow the client to manage = it, it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80= =9D field.


6) There is no standard = identifier for the request. Debugging and auditing are hampered by the = client and AS having no standard way to identifying a request. While one = AS may provide a unique URL for each grant request, another AS may use a = persistent "access token" to identify the grant request, and other ASs = may issue a new "access token" on each API call, providing no = persistent identifier for the request.

Debugging and auditing this kind of = thing are functions of the AS. How is interoperability harmed by = different ASs having different methods to identify their internal data = elements? The client doesn=E2=80=99t need any knowledge of the AS=E2=80=99= s identifiers, it just needs to know the next steps for continuing the = negotiation.

I = do agree that there=E2=80=99s a potential use for a consistent = identifier, for things like =E2=80=9Cextending a grant request=E2=80=9D, = and we need to look at that separately as it doesn=E2=80=99t need to be = exposed to the core protocol for most use cases.

 =E2=80=94 Justin


On Dec = 10, 2020, at 3:05 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

-1 per all the reasons I laid out = in https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6= UEVJN8hkY/
3D""=E1=90=A7

On Thu, Dec = 10, 2020 at 7:52 AM Justin Richer <jricher@mit.edu> wrote:
The editors and chairs would like to confirm = consensus on a current pull request:

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

This pull = request simplifies the continuation response and request by making the = access token mandatory, and it clarifies the responsibilities of the AS = in enforcing the security of the continuation request. Several WG = members expressed specific support for keeping the access token to = enable specific use cases, and there was general support for simplifying = the process from what it currently is in the draft. The editors believe = the pull request represents a solution that meets these goals.

This call is open until = Monday December 14. At that point, the PR will be merged unless the = chairs determine there is not rough consensus for its = inclusion.

Thank= you,

 - = Justin, Aaron, and Fabien
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_580D64E7-F73B-4B1C-B109-D7112C2ADAC9-- From nobody Fri Dec 11 10:12:38 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234D23A0DAE for ; Fri, 11 Dec 2020 10:12:36 -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 69LR-BpIzDqn for ; Fri, 11 Dec 2020 10:12:33 -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 B4D643A0DAD for ; Fri, 11 Dec 2020 10:12:33 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id n4so10371087iow.12 for ; Fri, 11 Dec 2020 10:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pEAZpIzFS8+afgmEzNFiBwRdqWGCFIZnp6B15YxDTX0=; b=LTqMqPdgfq6JyvSlvdBrwusgI/ngao9tCZlGJ5HV1pEpVuchlJpsaKKEzLkPr+YKkV yFg8ixeg8pjRR81M509uYitWpZW656b/erKOWAnOzYOm+18e2QnYgNOwnP564AcuOymO vz9auojAWUaHhyAWCT3tiSdl6K3MrbGDeGmr54Ew0zVYs2gZHSuOtuebj+mVSL0NILPU 8fhDBm26QPszKddd0CbK9lLQn/O9H1MlgVrcqYQLcvK/OiACVxXcZg4uo5rHjki1miB/ H2iXsxRI4aq570WaI61qD2O8dnF5u/5sTTwiGW92q5NeLHF14FtZZvlbyuRmuIHbhX4m dp3g== 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=pEAZpIzFS8+afgmEzNFiBwRdqWGCFIZnp6B15YxDTX0=; b=EwVKc2+yLILJAFSQIG03qN8+J4w0Av72mgJduKwMnKUiB3sMmOZnokAWEqrPQYdClM +pPtNkREC/wLfPLRUCnVHl7izeyWmYPSHu5I9yaW4JOtbvk9W8jyT7rDNWeZ3QwVdyNf VgDK6++l8ebePi3DQsGCzuOu7TKrWgPXP1J5/PO+9gZEaZusKX3dPAVCY10bU9zlwLte ysoMlvqROXSrecbDJ6Ah88OH6YrEzHC3BqYluOq2KMJVCMLkRKHU7NKmDiqqzId9t9/U rp0eVgPKmBI0bjrjkZIvl5PNeAvDTCzBSjS8N2KNIJzzu5ZGfTZcKAj2oOJGnqwDP1ao 2JLA== X-Gm-Message-State: AOAM530DFv4QvtuK62GitwzS96YmdcJNCq2noQLHWZzYQQ0pqUxgGeB3 5GO4ZbghH66+8ZM9wlKR3wtyYf6nk6TDJ3rYS7w= X-Google-Smtp-Source: ABdhPJzusFxquqe0+a6MVVTwhNxkrwdWkPiHrnEUXWQkyelAqwXROm90sSVXbSyQJglinci6z1vJq+RSbq+DNtpV/Dc= X-Received: by 2002:a05:6602:214b:: with SMTP id y11mr16555501ioy.78.1607710352726; Fri, 11 Dec 2020 10:12:32 -0800 (PST) MIME-Version: 1.0 References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> <21cf7c30-c42a-f29c-a407-7badde5c0151@free.fr> In-Reply-To: From: Fabien Imbault Date: Fri, 11 Dec 2020 19:12:21 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000079e3b205b6343c44" Archived-At: Subject: Re: [GNAP] RS-Token Introspection or RC-Token Introspection 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, 11 Dec 2020 18:12:36 -0000 --00000000000079e3b205b6343c44 Content-Type: text/plain; charset="UTF-8" Hi Denis, I agree that what you're saying makes sense. I'm just asking more broadly what people think of it (and trying to balance the risks and benefits of each approach). Fabien On Fri, Dec 11, 2020 at 6:56 PM Denis wrote: > Hi Fabien, > > Hi Denis, > > Please note that the token introspection is not a new idea, it's already > present in OAuth2 world (rfc 7662), and allows the RS to verify the access > token. > > I am pretty aware that token introspection is already present in the > OAuth2 world (rfc 7662). :-) > > In important point : RFC 7662 states "the contents of tokens are opaque to > clients". > The text does *not* state : "the contents of tokens are opaque to both > clients and Resource Servers (RSs). > > In the current version of GNAP, there is also section 6 that introduces > management endpoints, which could potentially be extended in a similar way > (currently this is not specified, the management endpoint is here for > rotation/revocation). Then the client could require more information on > what is included in the opaque token, but of course, this relies on the > assumption that the client trusts the AS. There is also the discussion on > the "resource" description in the response, that may provide a simpler > scheme (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141). > > But if we assume the AS may be malevolent (which is more likely if the AS > becomes a less central point, at least for some implementations), > then indeed receiving opaque tokens wouldn't provide all the guarantees, > as it may lie on what is really in the token (too many claims for > instance). > > > More specifically, while I recon there might be a risk which we'd rather > not have, I don't really think an opaque token is really an unmanageable > issue with privacy. > Suppose someone adds a field in a JWT, most likely you'll be able to > detect that. > > RFC 7662 has been made available primarily for "lazy" RSs. :-) > > Let us consider a case where the contents of access tokens are opaque to > both RCs and RSs. > Let us suppose that opaque access tokens contains only a temporary handle > to the set of claims related to the end-user, e.g. a 128 bits handle. > > Neither the RC, nor the RS would be able to understand it and the RS would > be forced to call back the AS. > Not only this call back will be bad in terms of the user's privacy because > the AS will be able to know exactly when the access token has been used > by the end-user but it would be impossible to detect it to prevent some > damage on the RS side. > We cannot assume that all future ASs in the world, while still providing > the requested claims, will never deliver more attributes than the ones > requested > by the RC and thus allow RSs (and possibly other servers) link their > users. > > > But suppose we go for non opaque tokens, then we'd need a way of > describing its format. Which might limit a bit the use cases if we're not > careful. > > In OAuth 2.0, it has been possible to describe a token format (JSON Web > Token (JWT) Profile for OAuth 2.0 Access Tokens). > I don't believe it would a "mission impossible" in this WG to describe a > GNAP format for access tokens. > > The IETF is supposed to standardize protocols at the bit level and this > has made its success. > > Denis > > > I'd be interested to know what others think, since it is diverging quite a > bit from the OAuth2 world (not a bad thing in itself but still). > > Fabien > > On Fri, Dec 11, 2020 at 12:04 PM Denis wrote: > >> Hi Fabien, >> >> This is a response only to the point 7 from the "Quick review of >> draft-ietf-gnap-core-protocol-00". >> The full original text with your comments is copied after my reply. >> >> In order to allow the RC to understand the content of an opaque token, >> you are proposing to support a Token Introspection query from the RC to the >> AS. >> This does not solve the concerns of a RC that wants to make sure that the >> access token does not contain claims that have not been requested. >> >> Let us illustrate the case by using an example: >> >> The RC asks to the AS to deliver an access token that contains an >> identifier only unique to the RS. >> In reality, the AS delivers an access token that does contain an >> identifier only unique to the RS >> but in addition a globally unique identifier. Since the access token is >> supposed to be opaque to the RC, >> the RC calls the AS to perform a Token Introspection operation. In its >> response, the AS presents an identifier >> that is indeed only unique to the RS but the AS voluntarily *omits *to >> present the globally unique identifier to the RC. >> >> In the same way, if Token Introspection is supported by a RS, that does >> not provide confidence to the end-user or to the RC. >> >> Let us illustrate the case by using another example: >> >> The AS delivers to the RC an access token that only contains an >> identifier unique to the RS. Since the access token >> is supposed to be opaque to the RS, the RS calls the AS to perform a >> Token Introspection operation. In its response, >> the AS presents an identifier that is indeed only unique to the RS but >> the AS voluntarily *adds *a globally unique identifier. >> >> *Conclusion*: In both cases, a globally unique identifier will be used >> by the RS without the RC or the end-user knowing it. >> Opaque tokens are in contradiction with the >> end-user's privacy. >> >> For end-users caring about their privacy (or for systems willing to >> protect the user's privacy), access tokens should not be considered >> to be opaque to RCs, nor to RSs, and ASs should not support Token >> Introspection, whether it is RS-Token Introspection or RC-Token >> Introspection. >> >> Denis >> >> >> 7. The content and the format of access tokens shall not be considered >>>>> to be opaque to the RC so that the RC can inspect it. >>>>> This is a matter of confidence to make sure for the RC (and for >>>>> the user) that no "extra" information has been included by the AS into the >>>>> access token. >>>>> >>>> [FI] This might go a bit further than the GNAP's mandate (especially if >>> it becomes a mandatory requirement). But supposing we support non-opaque >>> tokens, >>> does it preclude supporting opaque tokens? It's just a different trust >>> model, which makes sense if people agree with your premises (previous >>> items), >>> but that are less relevant if people still consider the AS as the >>> central piece. Also one great thing with opaque tokens is that it makes the >>> system easier to upgrade >>> (you don't really care about what a token is). >>> >>> [Denis] Privacy is not more relevant for an AS-centric model than for a >>> RS-centric model. In particular, a RC should be able to verify which kind >>> of end-user identifier claim >>> has been incorporated into the access token by the AS, in particular >>> whether it is globally unique, unique to the AS only, unique to the RS only >>> or ephemeral (valid for >>> that RS during a session with the AS). >>> >> [FI2] ok, see discussion on whether tokens should be opaque or not. >> >>> I suppose that the use of structured access tokens should be >>> recommended. This means,in particular, that from the very beginning, we >>> should incorporate a version number >>> inside each access token. >>> >>> One alternative way would be to allow RS call to AS for verification >>> (including revocation status) and include a checksum. >>> >>> [Denis] The RC, i.e. not the RS, should be able to perform such >>> verification before presenting the access token to the RS. So this >>> alternative way would not work. >>> >> [FI2] then there could be a similar API for the client (cf discussion on >> similarities between introspection/management APIs). >> >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000079e3b205b6343c44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

I agree that what you&#= 39;re saying makes sense.=C2=A0

I'm just askin= g more broadly what people think of it (and trying to balance the risks and= benefits of each approach).=C2=A0

Fabien

On = Fri, Dec 11, 2020 at 6:56 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hi Fabien,

=20
Hi Denis,=C2=A0

Please note that the token introspection is not a new idea, it's already present in OAuth2 world (rfc 7662), and allows the RS to verify the access token.

I am pretty aware that token introspection is already present in the OAuth2 world (rfc 7662). :-)

In important point : RFC 7662 states "the contents of tokens ar= e opaque to clients".
The text does not state : "the contents of tokens are opaque to both clients and Resource Servers (RSs).


In the current version of GNAP, there is also section 6 that introduces management endpoints, which could potentially be extended in a similar way (currently this is not specified, the management endpoint is here for rotation/revocation). Then the client could require more information on what is included in the opaque token, but of course, this relies on the assumption that the client trusts the AS.=C2=A0There is also the discussion on the "resource= " description in the response, that may provide a simpler scheme (https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/issues/141).=C2=A0
=C2=A0
But if we assume the AS may be malevolent=C2=A0(which is mor= e likely if the AS becomes a less central point, at least for some implementations),
then indeed receiving opaque tokens wouldn't provide all th= e guarantees, as it may lie on what is really in the token (too many claims for instance).

More specifically, while I recon there might be a risk which we'd rather not have, I don't really think an opa= que token is really an unmanageable issue with privacy.
Suppose someone adds a field in a JWT, most likely you'll b= e able to detect that.

RFC 7662 has been made available primarily for "lazy" RSs.= :-)

Let us consider a case where the contents of access tokens are opaque to both RCs and RSs.

Let us suppose that opaque access tokens contains only a temporary handle to the set of claims related to the end-user, e.g. a 128 bits handle.

Neither the RC, nor the RS would be able to understand it and the RS would be forced to call back the AS.
Not only this call back will be bad in terms of the user's privac= y because the AS will be able to know exactly when the access token has been used
by the end-user but it would be impossible to detect it to prevent some damage on the RS side.

We cannot assume that all future ASs in the world, while still providing the requested claims, will never deliver more attributes than the ones requested
by the RC and thus allow RSs (and possibly other servers) link their users.

But suppose we go for non opaque tokens, then we'd need = a way of describing its format. Which might limit a bit the use cases if we're not careful.

In OAuth 2.0, it has been possible to describe a token format (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens).
I don't believe it would a "mission impossible" in this= WG to describe a GNAP format for access tokens.

The IETF is supposed to standardize protocols at the bit level and this has made its success.

Denis


I'd be interested to know what others think, since it is diverging quite a bit from the OAuth2 world (not a bad thing in itself but still).=C2=A0

Fabien

On Fri, Dec 11, 2020 at 12:04 PM Denis <denis.ietf@free.fr> wrote:
Hi Fabien,

This is a response only to the point 7 from the "Quick review of draft-ietf-gnap-core-protocol-00"= ;.
The full original text with your comments is copied after my reply.

In order to allow the RC to understand the content of an opaque token, you are proposing to support a Token Introspection query from the RC to the AS.
This does not solve the concerns of a RC that wants to make sure that the access token does not contain claims that have not been requested.

Let us illustrate the case by using an example:

The RC asks to the AS to deliver an access token that contains an identifier only unique to the RS.
In reality, the AS delivers an access token that does contain an identifier only unique to the RS
but in addition a globally unique identifier. Since the access token is supposed to be opaque to the RC,
the RC calls the AS to perform a Token Introspection operation. In its response, the AS presents an identifier
that is indeed only unique to the RS but the AS voluntarily omits to present the globally unique identifier to the RC.

In the same way, if Token Introspection is supported by a RS, that does not provide confidence to the end-user or to the RC.

Let us illustrate the case by using another example:

The AS delivers to the RC an access token that only contains an identifier unique to the RS. Since the access token
is supposed to be opaque to the RS, the RS calls the AS to perform a Token Introspection operation. In its response,
the AS presents an identifier that is indeed only unique to the RS but the AS voluntarily adds a globally unique identifier.

Conclusion: In both cases, a globally unique identifier will be used by the RS without the RC or the end-user knowing it.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Opaque t= okens are in contradiction with the end-user's privacy.

For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
to be opaque to RCs, nor to RSs, and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

Denis


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
=C2=A0=C2=A0=C2=A0 This is a matter= of confidence to make sure for the RC (and for the user) that no "extra" information has b= een included by the AS into the access token.

[FI] This might go a bit further than the GNAP's=C2=A0mandat= e (especially if it becomes a mandatory requirement). But supposing we support non-opaque tokens,
does it preclude supporting opaque tokens? It's just a different trust model, which makes sense if people agree with your premises (previous items),
but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade
(you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for
that RS during a session with the AS).

[FI2] ok, see discussion on whether tokens should be opaque or not.

I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number
inside each access token.


One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum.

[Denis]=C2=A0 The RC, i.e. not the RS, should be abl= e to perform such verification before presenting the access token to the RS. So this alternative way would not work.

[FI2] then there could be a similar API for the client (cf discussion on similarities between introspection/management APIs).


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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000079e3b205b6343c44-- From nobody Fri Dec 11 10:12:58 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B333A0DAE for ; Fri, 11 Dec 2020 10:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OptLs0p95Es for ; Fri, 11 Dec 2020 10:12:55 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D083A0DBA for ; Fri, 11 Dec 2020 10:12:54 -0800 (PST) Received: from [192.168.1.11] ([90.91.135.71]) by mwinf5d60 with ME id 36Cq240091Ybo4i036Cqte; Fri, 11 Dec 2020 19:12:50 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 11 Dec 2020 19:12:50 +0100 X-ME-IP: 90.91.135.71 To: txauth@ietf.org References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> From: Denis Message-ID: <9fce631f-e4fb-2f10-a504-139fe5936a9d@free.fr> Date: Fri, 11 Dec 2020 19:12:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> Content-Type: multipart/alternative; boundary="------------42B2778D8D682DD3336CB563" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 18:12:57 -0000 This is a multi-part message in MIME format. --------------42B2778D8D682DD3336CB563 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, My two cents. I fear we might have a vocabulary problem. At the moment an access token is issued by an Authorization Server (AS) and consumed by a Resource Server (RS). Changing this would create confusion. * If a similar data structure as the one currently used in an access token would be exchanged between the RC and the AS, let us call it differently: xxxxxx token. * If a similar data structure as the one currently used in an access token is not exchanged between the RC and the AS, then there is no terminology problem. Denis > Others had already responded to this previous thread, but I wanted to > add a couple points to clarify some things. > >> 3) What the client has to do with the "access token" is not the same >> as access tokens for an RS. The client gets a new "access token" for >> each grant request, and for each API call to the AS, and the client >> learns it can not make any more API calls for that specific request >> when it does not get an "access token" back. This is a completely >> different design pattern than calling an RS API with an access >> token, and is a new design pattern for calling APIs. This adds >> complexity to the client that it would not normally have, and I don't >> think GNAP is the right place to start a new design pattern. >> > > I’m not sure what you mean by these being different — the whole point > of the design is that the client would be doing the same thing with > the access token at the AS that it does with the RS by re-using the > access token structure. Can you please describe what the differences > are, apart from the rotation? Presentation of the token and signing of > the message are identical. > > Rotation of the access token and artifacts for ongoing continuation > responses is a separate issue to be discussed: > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 > > > And for what it’s worth, GNAP is absolutely the right place to have > new designs — not that this is one. > >> 4) Clients that only want claims from the AS and no access tokens >> will be required to support an API calling mechanism they would not >> have to support otherwise. > > Correct, but the delta between the calls a client would make with and > without an access token is vanishingly small. The client has to sign > the initial request in some fashion, and it will sign the continuation > request in the same exact fashion, but now include an access token in > that request. > > Clients making a request to an AS and not getting an access token is a > new design pattern. I think it has value and should be included, but > OAuth today shows us the immense value of getting access tokens for > calling APIs, and so we shouldn’t optimize away from that pattern. > >> >> 5) If the AS does not provide an "access token", there is no >> mechanism for a client to delete the request, as the client is not >> allowed to make a call without an "access token". > > More properly, if the AS does not provide a “continue” field then the > client can’t delete the request — and yes, that’s intentional. The AS > is telling this client instance that it can’t do anything else with > this ongoing request. If the AS wants to allow the client to manage > it, it will include the mechanisms to do so in the “continue” field. > >> >> 6) There is no standard identifier for the request. Debugging and >> auditing are hampered by the client and AS having no standard way to >> identifying a request. While one AS may provide a unique URL for each >> grant request, another AS may use a persistent "access token" to >> identify the grant request, and other ASs may issue a new "access >> token" on each API call, providing no persistent identifier for the >> request. > > Debugging and auditing this kind of thing are functions of the AS. How > is interoperability harmed by different ASs having different methods > to identify their internal data elements? The client doesn’t need any > knowledge of the AS’s identifiers, it just needs to know the next > steps for continuing the negotiation. > > I do agree that there’s a potential use for a consistent identifier, > for things like “extending a grant request”, and we need to look at > that separately as it doesn’t need to be exposed to the core protocol > for most use cases. > >  — Justin > > >> On Dec 10, 2020, at 3:05 PM, Dick Hardt > > wrote: >> >> -1 per all the reasons I laid out in >> https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ >> >> ᐧ >> >> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer > > wrote: >> >> The editors and chairs would like to confirm consensus on a >> current pull request: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >> >> >> This pull request simplifies the continuation response and >> request by making the access token mandatory, and it clarifies >> the responsibilities of the AS in enforcing the security of the >> continuation request. Several WG members expressed specific >> support for keeping the access token to enable specific use >> cases, and there was general support for simplifying the process >> from what it currently is in the draft. The editors believe the >> pull request represents a solution that meets these goals. >> >> This call is open until Monday December 14. At that point, the PR >> will be merged unless the chairs determine there is not rough >> consensus for its inclusion. >> >> Thank you, >> >>  - Justin, Aaron, and Fabien >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> > > --------------42B2778D8D682DD3336CB563 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi,

My two cents.

I fear we might have a vocabulary problem. At the moment an access token is issued by an Authorization Server (AS) and consumed by a Resource Server (RS).
Changing this would create confusion.
  • If a similar data structure as the one currently used in an access token would be exchanged between the RC and the AS,
    let us call it differently: xxxxxx token.
  • If a similar data structure as the one currently used in an access token is not exchanged between the RC and the AS, then
    there is no terminology problem.
Denis


Others had already responded to this previous thread, but I wanted to add a couple points to clarify some things.

3) What the client has to do with the "access token" is not the same as access tokens for an RS. The client gets a new "access token" for each grant request, and for each API call to the AS, and the client learns it can not make any more API calls for that specific request when it does not get an "access token" back. This is a completely different design pattern than calling an RS API with an access token, and is a new design pattern for calling APIs. This adds complexity to the client that it would not normally have, and I don't think GNAP is the right place to start a new design pattern.


I’m not sure what you mean by these being different — the whole point of the design is that the client would be doing the same thing with the access token at the AS that it does with the RS by re-using the access token structure. Can you please describe what the differences are, apart from the rotation? Presentation of the token and signing of the message are identical.

Rotation of the access token and artifacts for ongoing continuation responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87

And for what it’s worth, GNAP is absolutely the right place to have new designs — not that this is one.

4) Clients that only want claims from the AS and no access tokens will be required to support an API calling mechanism they would not have to support otherwise. 

Correct, but the delta between the calls a client would make with and without an access token is vanishingly small. The client has to sign the initial request in some fashion, and it will sign the continuation request in the same exact fashion, but now include an access token in that request. 

Clients making a request to an AS and not getting an access token is a new design pattern. I think it has value and should be included, but OAuth today shows us the immense value of getting access tokens for calling APIs, and so we shouldn’t optimize away from that pattern.


5) If the AS does not provide an "access token", there is no mechanism for a client to delete the request, as the client is not allowed to make a call without an "access token".

More properly, if the AS does not provide a “continue” field then the client can’t delete the request — and yes, that’s intentional. The AS is telling this client instance that it can’t do anything else with this ongoing request. If the AS wants to allow the client to manage it, it will include the mechanisms to do so in the “continue” field.


6) There is no standard identifier for the request. Debugging and auditing are hampered by the client and AS having no standard way to identifying a request. While one AS may provide a unique URL for each grant request, another AS may use a persistent "access token" to identify the grant request, and other ASs may issue a new "access token" on each API call, providing no persistent identifier for the request.

Debugging and auditing this kind of thing are functions of the AS. How is interoperability harmed by different ASs having different methods to identify their internal data elements? The client doesn’t need any knowledge of the AS’s identifiers, it just needs to know the next steps for continuing the negotiation.

I do agree that there’s a potential use for a consistent identifier, for things like “extending a grant request”, and we need to look at that separately as it doesn’t need to be exposed to the core protocol for most use cases.

 — Justin


On Dec 10, 2020, at 3:05 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

ᐧ

On Thu, Dec 10, 2020 at 7:52 AM Justin Richer <jricher@mit.edu> wrote:
The editors and chairs would like to confirm consensus on a current pull request:


This pull request simplifies the continuation response and request by making the access token mandatory, and it clarifies the responsibilities of the AS in enforcing the security of the continuation request. Several WG members expressed specific support for keeping the access token to enable specific use cases, and there was general support for simplifying the process from what it currently is in the draft. The editors believe the pull request represents a solution that meets these goals.

This call is open until Monday December 14. At that point, the PR will be merged unless the chairs determine there is not rough consensus for its inclusion.

Thank you,

 - Justin, Aaron, and Fabien
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth



--------------42B2778D8D682DD3336CB563-- From nobody Fri Dec 11 10:24:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33CB3A0DCD for ; Fri, 11 Dec 2020 10:24:53 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2sW_mOOMenN for ; Fri, 11 Dec 2020 10:24:51 -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 5C7833A0CF4 for ; Fri, 11 Dec 2020 10:24:51 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id q137so10408027iod.9 for ; Fri, 11 Dec 2020 10:24:51 -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=tlWio9eipQo9PPkRjDyn88BEFNBLCdmgT0H26vxBvFw=; b=rO+ZU4a9dRdj+fOQomx/x7BTqqjPvpzxAFeIMqideAyU0UNWiFzItKaGT0x8PsjLNM kmyI8WZ0scFGyTmwXi9UEZNY9ufLcdZAJFW/Dl6kZ3Kte7MkVBpEZtir8aM324Zw4IAH dHNzf0eR4vz0I2p4Yzyr4W1sFd46LmyNE75MEYhVQOXLTDCbmN7KPpQtR9CuoRC2dEwC iHQnuVOaxEUdoCYGPXsZ1XKLtY5YDFcXiMzYGA55z+62bzIMNxbhec9/TUUS4d0I3pxR ul956gIYXbltKc8Sc/hPaX4ZSotQtzw1PpQ68uns3jwPj/gw5OYOPZpWr2ZcOokXsXG9 ImuQ== 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=tlWio9eipQo9PPkRjDyn88BEFNBLCdmgT0H26vxBvFw=; b=tgJffkB9oUsgBlXB6miR68yFt10YKdRnRmN8kyzvgkxdPtPXDTnM2MK/X6K8A6u3X+ Wk2s1EO84PoB/1s908s+LV6p9UZ1KSwQTHS439YOnFu7RWu4WvopW2JGJF5R3iCmmzDm yFymc/u+AKKrRoAdh2i9d4pmoriOBsPdwU7EKJiEs4YO90gg2zx1yI6oxtsa1X8N/cUc YHfAl/lSeohmx3jOcxCopFRmSJ2hnswKl9Fx4sbH0weFn7whO6pHO4CVpKGzrwfyQU6T jdklf55Xa+6+JxDHiHiH6fxVGva5viSsrEln6dlSov2nYg5ZTz5FboQtSh2GEq226n6m 0wGg== X-Gm-Message-State: AOAM5304D1wyTmgObeUYozQ2Xvp1QD9wsSTO/yxTP+Q+S/4DwhPjeB7g bhLpS+Bd4SGXoXaQQgCHT+/ICcMQ8fJy2hNFmSc= X-Google-Smtp-Source: ABdhPJwFcUYx0x7pKHnlwlXxztwwrzj28g1D+siPI5YbynVlfZzXO9/h1fmf5DqgEuYidxm72m1AH6N9wqOe7Rp3MV4= X-Received: by 2002:a5e:a815:: with SMTP id c21mr15874113ioa.141.1607711090531; Fri, 11 Dec 2020 10:24:50 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> <9fce631f-e4fb-2f10-a504-139fe5936a9d@free.fr> In-Reply-To: <9fce631f-e4fb-2f10-a504-139fe5936a9d@free.fr> From: Fabien Imbault Date: Fri, 11 Dec 2020 19:24:39 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000073df3505b63468a6" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 18:24:54 -0000 --00000000000073df3505b63468a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, Well we're not doing exactly the same as OAuth. I don't think this would create confusion in the context of GNAP, we would adapt the vocabulary to what the protocol specifies. Fabien On Fri, Dec 11, 2020 at 7:13 PM Denis wrote: > Hi, > > My two cents. > > I fear we might have a vocabulary problem. At the moment an access token > is issued by an Authorization Server (AS) and consumed by a Resource Serv= er > (RS). > Changing this would create confusion. > > - If a similar data structure as the one currently used in an access > token would be exchanged between the RC and the AS, > let us call it differently: xxxxxx token. > > > - If a similar data structure as the one currently used in an access > token is not exchanged between the RC and the AS, then > there is no terminology problem. > > Denis > > > Others had already responded to this previous thread, but I wanted to add > a couple points to clarify some things. > > 3) What the client has to do with the "access token" is not the same as > access tokens for an RS. The client gets a new "access token" for each > grant request, and for each API call to the AS, and the client learns it > can not make any more API calls for that specific request when it does no= t > get an "access token" back. This is a completely different design pattern > than calling an RS API with an access token, and is a new design pattern > for calling APIs. This adds complexity to the client that it would not > normally have, and I don't think GNAP is the right place to start a new > design pattern. > > > I=E2=80=99m not sure what you mean by these being different =E2=80=94 the= whole point of > the design is that the client would be doing the same thing with the acce= ss > token at the AS that it does with the RS by re-using the access token > structure. Can you please describe what the differences are, apart from t= he > rotation? Presentation of the token and signing of the message are > identical. > > Rotation of the access token and artifacts for ongoing continuation > responses is a separate issue to be discussed: > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 > > And for what it=E2=80=99s worth, GNAP is absolutely the right place to ha= ve new > designs =E2=80=94 not that this is one. > > 4) Clients that only want claims from the AS and no access tokens will be > required to support an API calling mechanism they would not have to suppo= rt > otherwise. > > > Correct, but the delta between the calls a client would make with and > without an access token is vanishingly small. The client has to sign the > initial request in some fashion, and it will sign the continuation reques= t > in the same exact fashion, but now include an access token in that reques= t. > > Clients making a request to an AS and not getting an access token is a ne= w > design pattern. I think it has value and should be included, but OAuth > today shows us the immense value of getting access tokens for calling API= s, > and so we shouldn=E2=80=99t optimize away from that pattern. > > > 5) If the AS does not provide an "access token", there is no mechanism fo= r > a client to delete the request, as the client is not allowed to make a ca= ll > without an "access token". > > > More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D fi= eld then the > client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99s= intentional. The AS is > telling this client instance that it can=E2=80=99t do anything else with = this > ongoing request. If the AS wants to allow the client to manage it, it wil= l > include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. > > > 6) There is no standard identifier for the request. Debugging and auditin= g > are hampered by the client and AS having no standard way to identifying a > request. While one AS may provide a unique URL for each grant request, > another AS may use a persistent "access token" to identify the grant > request, and other ASs may issue a new "access token" on each API call, > providing no persistent identifier for the request. > > > Debugging and auditing this kind of thing are functions of the AS. How is > interoperability harmed by different ASs having different methods to > identify their internal data elements? The client doesn=E2=80=99t need an= y > knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for > continuing the negotiation. > > I do agree that there=E2=80=99s a potential use for a consistent identifi= er, for > things like =E2=80=9Cextending a grant request=E2=80=9D, and we need to l= ook at that > separately as it doesn=E2=80=99t need to be exposed to the core protocol = for most > use cases. > > =E2=80=94 Justin > > > On Dec 10, 2020, at 3:05 PM, Dick Hardt wrote: > > -1 per all the reasons I laid out in > https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ > =E1=90=A7 > > On Thu, Dec 10, 2020 at 7:52 AM Justin Richer wrote: > >> The editors and chairs would like to confirm consensus on a current pull >> request: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 >> >> This pull request simplifies the continuation response and request by >> making the access token mandatory, and it clarifies the responsibilities= of >> the AS in enforcing the security of the continuation request. Several WG >> members expressed specific support for keeping the access token to enabl= e >> specific use cases, and there was general support for simplifying the >> process from what it currently is in the draft. The editors believe the >> pull request represents a solution that meets these goals. >> >> This call is open until Monday December 14. At that point, the PR will b= e >> merged unless the chairs determine there is not rough consensus for its >> inclusion. >> >> Thank you, >> >> - Justin, Aaron, and 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 > --00000000000073df3505b63468a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0

Well we're not doin= g exactly the same as OAuth.
I don't think this would create = confusion in the context of GNAP, we would adapt the vocabulary to what the= protocol specifies.=C2=A0

Fabien

<= div class=3D"gmail_quote">
On Fri, Dec= 11, 2020 at 7:13 PM Denis <denis.= ietf@free.fr> wrote:
=20 =20 =20
Hi,

My two cents.

I fear we might have a vocabulary problem. At the moment an access token is issued by an Authorization Server (AS) and consumed by a Resource Server (RS).
Changing this would create confusion.
  • If a similar data structure as the one currently used in an access token would be exchanged between the RC and the AS,
    let us call it differently: xxxxxx token.
  • If a similar data structure as the one currently used in an access token is not exchanged between the RC and the AS, then
    there is no terminology problem.
Denis


=20 Others had already responded to this previous thread, but I wanted to add a couple points to clarify some things.

3) What the client has to do with the "access token" is not the same as access tokens for an RS. The client gets a new "access token" for each grant reque= st, and for each API call to the AS, and the client learns it can not make any more API calls for that specific request when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access token,=C2=A0and is a new design pattern for calling APIs= . This adds complexity to the client that it would not normally have, and I don't think GNAP is the right place to start a new design pattern.


I=E2=80=99m not sure what you mean by these being different =E2=80=94 the whole point of the design is that the cli= ent would be doing the same thing with the access token at the AS that it does with the RS by re-using the access token structure. Can you please describe what the differences are, apart from the rotation? Presentation of the token and signing of the message are identical.

Rotation of the access token and artifacts for ongoing continuation responses is a separate issue to be discussed:=C2=A0https://github.com/ietf-wg-gnap/g= nap-core-protocol/issues/87

And for what it=E2=80=99s worth, GNAP is absolutely the right place to have new designs =E2=80=94 not that this is one.
4) Clients that only want claims from the AS and no access tokens will be required to support an API calling mechanism they would not have to support otherwise.=C2=A0

Correct, but the delta between the calls a client would make with and without an access token is vanishingly small. The client has to sign the initial request in some fashion, and it will sign the continuation request in the same exact fashion, but now include an access token in that request.=C2=A0

Clients making a request to an AS and not getting an access token is a new design pattern. I think it has value and should be included, but OAuth today shows us the immense value of getting access tokens for calling APIs, and so we shouldn=E2=80=99t optimize away from that pattern.


5) If the AS does not provide an "access token", there is no mechanism for a client to delete the request, as the client is not allowed to make a call without an "acces= s token".

More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2=80=99t de= lete the request =E2=80=94 and yes, that=E2=80=99s intentional. The AS is telling this clien= t instance that it can=E2=80=99t do anything else with this ongoing request. If the AS wants to allow the client to manage it, it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2= =80=9D field.


6) There is no standard identifier for the request. Debugging and auditing are hampered by the client and AS having no standard way to identifying a request. While one AS may provide a unique URL for each grant request, another AS may use a persistent "access token&quo= t; to identify the grant request, and other ASs may=C2=A0issue a new "access token" on each API call, providing no persist= ent identifier for the request.

Debugging and auditing this kind of thing are functions of the AS. How is interoperability harmed by different ASs having different methods to identify their internal data elements? The client doesn=E2=80=99t need any knowledge of the AS=E2=80=99s ident= ifiers, it just needs to know the next steps for continuing the negotiation.

I do agree that there=E2=80=99s a potential use for a consistent identifier, for things like =E2=80=9Cextending a grant request=E2=80=9D, and we need to look at that separately as it does= n=E2=80=99t need to be exposed to the core protocol for most use cases.

=C2=A0=E2=80=94 Justin


On Dec 10, 2020, at 3:05 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=20
3D""=E1=90=A7

On Thu, Dec 10, 2020 at 7:52 AM Justin Richer <jricher@mit.edu> wrote:
The editors and chairs would like to confirm consensus on a current pull request:


This pull request simplifies the continuation response and request by making the access token mandatory, and it clarifies the responsibilities of the AS in enforcing the security of the continuation request. Several WG members expressed specific support for keeping the access token to enable specific use cases, and there was general support for simplifying the process from what it currently is in the draft. The editors believe the pull request represents a solution that meets these goals.

This call is open until Monday December 14. At that point, the PR will be merged unless the chairs determine there is not rough consensus for its inclusion.

Thank you,

=C2=A0- Justin, Aaron, and Fabien
--
TXAuth mailing list
TXAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/= txauth



--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000073df3505b63468a6-- From nobody Fri Dec 11 12:03:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6A93A0F02 for ; Fri, 11 Dec 2020 12:03:26 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNZsFNj-5VGU for ; Fri, 11 Dec 2020 12:03:21 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450: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 78BA13A0EDF for ; Fri, 11 Dec 2020 12:03:19 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id l11so15022028lfg.0 for ; Fri, 11 Dec 2020 12:03:19 -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=OSO4ysEuNrccj2r/ifQIpBC/+meor5kmTBvLXxmNfAg=; b=AYHgblyGGQ4EG9BijH0wzar8ZCDIUyNAhVID4fjo9ayZc7e55f/yAQL7cI/HA49LNC N5njD7SqxRb0o2Va/G5ErTUwLUTo+dJrpDP20kmUIOBD3nEsYyScNYXpzN5Ijy4z9sDk dhbycKNI76nofIqbIUOL+GZ2fAFHvwP978kVZ0GWwNuZbvSP2mizjBSYdo6tnCgIhzZy GdEfuXTX49eb4QhE4RMvyJUTdHK4pSmKa5pQKKJIXIMEXiPA6OzIKefN3SnPTaOTW0Hc qQ+FN6YxVkW2ipsm6aSBPqrcMY0haUD1LtfLZULWneDzwv3DVRrXwuYPe6CAOFfhXtbs JCZw== 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=OSO4ysEuNrccj2r/ifQIpBC/+meor5kmTBvLXxmNfAg=; b=AwSHKq3a7eU/vFNlhNAKusbcfNm+PMsXHdv8v4raMUFz4G3Nu0WShNGge1xS3/oDKj tibiTzH0RMLbcORBqWGbSpxuCTucqT2+aiKuKApeiLQpg9/MzfLTGNILLbfyLZ3JPzqJ cXLLIagdM9oTFBLuBr/j8LmVQdnaxlp/PPgmvAcR4ejcMVGdBnWJff6jR/cKVm59foaU ACK96vtqPViYcNc6WgIVXViCZiZTHgGZ1pdMURteBykzU0XeSogN0hS325zC+Ekfthfw stRUqfi9k0NrDd6XRkabrBeZ7zs0QBmbcDgYsIo4YeZGQOZ0B9WaNzd/AVKPHD7pc0+X +K0A== X-Gm-Message-State: AOAM532bzcy0XAzU+UVmTgbf7MROJCc3wptLKiSlyNcvLJD4cFna2IHi g3zvfBCsuPPNLnjbkjROLqvlX286uLDqAnLdEBM= X-Google-Smtp-Source: ABdhPJydM6i2FVTbHoJ+fIZ8lBcWBMLcWelb66Zdq7KnPJ3x7QsjpyiZzBEbKnfu8qBSbsorXEQiJyQNCgdw4HFLwyE= X-Received: by 2002:a19:58e:: with SMTP id 136mr5311383lff.98.1607716997239; Fri, 11 Dec 2020 12:03:17 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> From: Dick Hardt Date: Fri, 11 Dec 2020 12:02:41 -0800 Message-ID: To: Justin Richer Cc: txauth gnap Content-Type: multipart/alternative; boundary="0000000000008522fa05b635c851" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 20:03:34 -0000 --0000000000008522fa05b635c851 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable inline ... On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote: > Others had already responded to this previous thread, but I wanted to add > a couple points to clarify some things. > > 3) What the client has to do with the "access token" is not the same as > access tokens for an RS. The client gets a new "access token" for each > grant request, and for each API call to the AS, and the client learns it > can not make any more API calls for that specific request when it does no= t > get an "access token" back. This is a completely different design pattern > than calling an RS API with an access token, and is a new design pattern > for calling APIs. This adds complexity to the client that it would not > normally have, and I don't think GNAP is the right place to start a new > design pattern. > > > I=E2=80=99m not sure what you mean by these being different =E2=80=94 the= whole point of > the design is that the client would be doing the same thing with the acce= ss > token at the AS that it does with the RS by re-using the access token > structure. Can you please describe what the differences are, apart from t= he > rotation? Presentation of the token and signing of the message are > identical. > The client is getting the "access token" from its API. It is not using an "access_token" in other API calls to the AS. > > Rotation of the access token and artifacts for ongoing continuation > responses is a separate issue to be discussed: > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 > > And for what it=E2=80=99s worth, GNAP is absolutely the right place to ha= ve new > designs =E2=80=94 not that this is one. > You are proposing a new way for an API to provide context for subsequent API calls. Looks out of scope to me. > > 4) Clients that only want claims from the AS and no access tokens will be > required to support an API calling mechanism they would not have to suppo= rt > otherwise. > > > Correct, but the delta between the calls a client would make with and > without an access token is vanishingly small. The client has to sign the > initial request in some fashion, and it will sign the continuation reques= t > in the same exact fashion, but now include an access token in that reques= t. > Per my other point, there is no value to me in my implementations of passing context back and forth between the client and AS -- so it is extra work providing no value. Also, any client authentication mechanism that wants to use the HTTP Authentication header is precluded from using it. > > Clients making a request to an AS and not getting an access token is a ne= w > design pattern. I think it has value and should be included, but OAuth > today shows us the immense value of getting access tokens for calling API= s, > and so we shouldn=E2=80=99t optimize away from that pattern. > > > 5) If the AS does not provide an "access token", there is no mechanism fo= r > a client to delete the request, as the client is not allowed to make a ca= ll > without an "access token". > > > More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D fi= eld then the > client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99s= intentional. The AS is > telling this client instance that it can=E2=80=99t do anything else with = this > ongoing request. If the AS wants to allow the client to manage it, it wil= l > include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. > There is nuance in that intention. A related concern is that deleting a request does not seem like it is a "continue" operation. > > > 6) There is no standard identifier for the request. Debugging and auditin= g > are hampered by the client and AS having no standard way to identifying a > request. While one AS may provide a unique URL for each grant request, > another AS may use a persistent "access token" to identify the grant > request, and other ASs may issue a new "access token" on each API call, > providing no persistent identifier for the request. > > > Debugging and auditing this kind of thing are functions of the AS. How is > interoperability harmed by different ASs having different methods to > identify their internal data elements? The client doesn=E2=80=99t need an= y > knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for > continuing the negotiation. > Debugging between the client and the AS was what I was referring to. How does a client developer identify the request when communicating to the AS developer. Seems complicated. =E1=90=A7 --0000000000008522fa05b635c851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
inline ...=C2=A0

On Fri, Dec 11, 2020 at 9= :58 AM Justin Richer <jricher@mit.edu= > wrote:
=
Others had already responded to t= his previous thread, but I wanted to add a couple points to clarify some th= ings.

3) What the client has to do w= ith the "access token" is not the same as access tokens for an RS= . The client gets a new "access token" for each grant request, an= d for each API call to the AS, and the client learns it can not make any mo= re API calls for that specific request when it does not get an "access= token" back. This is a completely different design pattern than calli= ng an RS API with an access token,=C2=A0and is a new design pattern for cal= ling APIs. This adds complexity to the client that it would not normally ha= ve, and I don't think GNAP is the right place to start a new design pat= tern.


I=E2=80=99m not = sure what you mean by these being different =E2=80=94 the whole point of th= e design is that the client would be doing the same thing with the access t= oken at the AS that it does with the RS by re-using the access token struct= ure. Can you please describe what the differences are, apart from the rotat= ion? Presentation of the token and signing of the message are identical.

The client is getting the &= quot;access token" from its API. It is not using an "access_token= " in other API calls to the AS.
=C2=A0

Rotation of the access token and artifacts for on= going continuation responses is a separate issue to be discussed:=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87




<= /div>
Also, any client authentication mechanism=C2=A0that wants to use = the HTTP Authentication header is precluded from using it.

=C2=A0

Clients maki= ng a request to an AS and not getting an access token is a new design patte= rn. I think it has value and should be included, but OAuth today shows us t= he immense value of getting access tokens for calling APIs, and so we shoul= dn=E2=80=99t optimize away from that pattern.


5) If the AS does not provide an "access tok= en", there is no mechanism for a client to delete the request, as the = client is not allowed to make a call without an "access token".

More properly, if the AS does not prov= ide a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2=80=99t delete= the request =E2=80=94 and yes, that=E2=80=99s intentional. The AS is telli= ng this client instance that it can=E2=80=99t do anything else with this on= going request. If the AS wants to allow the client to manage it, it will in= clude the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field.

There is nuance in that inten= tion. A related concern is that deleting a request does not seem like it is= a "continue" operation.
=C2=A0


6) There is no st= andard identifier for the request. Debugging and auditing are hampered by t= he client and AS having no standard way to identifying a request. While one= AS may provide a unique URL for each grant request, another AS may use a p= ersistent "access token" to identify the grant request, and other= ASs may=C2=A0issue a new "access token" on each API call, provid= ing no persistent identifier for the request.

Debugging and auditing this kind of thing are functions of the AS. How = is interoperability harmed by different ASs having different methods to ide= ntify their internal data elements? The client doesn=E2=80=99t need any kno= wledge of the AS=E2=80=99s identifiers, it just needs to know the next step= s for continuing the negotiation.

Debugging between the client and the AS was what I was referring to. How= does a client developer identify the request when communicating to the AS = developer. Seems complicated.
=C2=A0
--0000000000008522fa05b635c851-- From nobody Fri Dec 11 14:02:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5551D3A1001 for ; Fri, 11 Dec 2020 14:01:55 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIQbjsvjVI16 for ; Fri, 11 Dec 2020 14:01:53 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 446493A1020 for ; Fri, 11 Dec 2020 14:01:52 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id j17so9393146ybt.9 for ; Fri, 11 Dec 2020 14:01:52 -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=0hZ3pYdDcjkRUAf0PdAxOyIVLbqlOsr4slbYeGVGKt4=; b=pbDx44NSDOxoXPcq8/MjUyONWdbcRElnXpPIfVE5U1oetNQw3ntgERyOCnmahtqpwm UMFvzjmUydPU6ysRpoWXfLQxjz//a6TlCGOmO6CBUbpZTdF5L8mXhUAZ5+7nZUf1gFqu F/ohmoDcV1FnKW74i+XDaL04u7iFDgaywRk+DOb+hF5tErNlJlzLYl6ZA0Z3SMXR7gA+ YbdnitfoSFwhFIZVgcE9/WiIZHIzurOJ0cHVHoVkuhO2vP/Dc/z8+NKnvd4h14XiZrPP SuA82/33WCdIqhTzAoE1rvIoPBG96xRi7EJOinY3XZDUapOaYLTX+wsL7lE89e3C4MET 8vzA== 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=0hZ3pYdDcjkRUAf0PdAxOyIVLbqlOsr4slbYeGVGKt4=; b=WRBUMSzDod+MB3sq/UANsjMBmkaXMeIRJVFkSyBbchWy0opf0pLVl7qxBAs6wKKvh5 uicAzoiT8d7ljzNifbrVRJUeCcDHtXZtg6e1BtQsRNMImz0MVFvHkI05J9ehbqE9c4xW L8eHA2fnwUqvHP/IDy5pGIUvxNrBsbO8n/p0vI4Y9s4L7y7w6qnTfwcBJ+MViqlYoIqD cvreaWidqLDcxMDhH/CSKZi+hzIDWP94kKAoU1368oPZt4y0VOYOtnvjCSI9prhCHFg/ oc6p51srsNMKLkLNKl0pvTzeXHbTcYoDPI63SfKbg+jtZRRf08gQ9MxM9snRXmOj1HHd jMMw== X-Gm-Message-State: AOAM532mfhe8ahI18TSd2tBO4TkK1qAv23fZI18VRuTtfBp5epwT3vy/ dwjCim9ccEYXljM6p/ESniTH5217sbVxSr/Thhw= X-Google-Smtp-Source: ABdhPJwUAF08lWgS9NgglPnFbYPIURjNg6muw3WxHIfcQQllWLra0FNfWZTW9dlrrjGFlGZ6SM0Z/IcFk/9O7z24sC0= X-Received: by 2002:a25:504c:: with SMTP id e73mr23250143ybb.84.1607724111321; Fri, 11 Dec 2020 14:01:51 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Stephen Moore Date: Fri, 11 Dec 2020 17:01:40 -0500 Message-ID: To: Dick Hardt Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="0000000000008d5dde05b637706c" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 22:02:03 -0000 --0000000000008d5dde05b637706c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Even though I've only been lightly following things, I feel the need to voice my preference as a developer since I will probably someday have to either write a RC or RS... The way I see it is the RC makes the initial request to the AS as part of this request, it provides it's key in the body... (So no use of the Authorization header) At this point that request, represented by the continue URL + "Access Token", from my lazy developer standpoint, is a Resource Endpoint and Access Token, and the AS is acting as a specialized RS in this case. So my client posts to whatever URL with the 'access token' in the authorization header, just like acting on any other resource I have a token for. YES, I get a new token value to use every call, and there is a decision point of "Do I have another continue, or do I have a real token for the resource..." But the mechanism is the same to me in the client. Personally I like that, because if I have an access_token, I already think "Put it in the auth header." So my vote would be +1 for the pull request at this time. -steve On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt wrote: > inline ... > > On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote: > >> Others had already responded to this previous thread, but I wanted to ad= d >> a couple points to clarify some things. >> >> 3) What the client has to do with the "access token" is not the same as >> access tokens for an RS. The client gets a new "access token" for each >> grant request, and for each API call to the AS, and the client learns it >> can not make any more API calls for that specific request when it does n= ot >> get an "access token" back. This is a completely different design patter= n >> than calling an RS API with an access token, and is a new design pattern >> for calling APIs. This adds complexity to the client that it would not >> normally have, and I don't think GNAP is the right place to start a new >> design pattern. >> >> >> I=E2=80=99m not sure what you mean by these being different =E2=80=94 th= e whole point of >> the design is that the client would be doing the same thing with the acc= ess >> token at the AS that it does with the RS by re-using the access token >> structure. Can you please describe what the differences are, apart from = the >> rotation? Presentation of the token and signing of the message are >> identical. >> > > The client is getting the "access token" from its API. It is not using an > "access_token" in other API calls to the AS. > > >> >> Rotation of the access token and artifacts for ongoing continuation >> responses is a separate issue to be discussed: >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >> >> And for what it=E2=80=99s worth, GNAP is absolutely the right place to h= ave new >> designs =E2=80=94 not that this is one. >> > > You are proposing a new way for an API to provide context for subsequent > API calls. Looks out of scope to me. > > >> >> 4) Clients that only want claims from the AS and no access tokens will b= e >> required to support an API calling mechanism they would not have to supp= ort >> otherwise. >> >> >> Correct, but the delta between the calls a client would make with and >> without an access token is vanishingly small. The client has to sign the >> initial request in some fashion, and it will sign the continuation reque= st >> in the same exact fashion, but now include an access token in that reque= st. >> > > Per my other point, there is no value to me in my implementations of > passing context back and forth between the client and AS -- so it is extr= a > work providing no value. > > Also, any client authentication mechanism that wants to use the HTTP > Authentication header is precluded from using it. > > > >> >> Clients making a request to an AS and not getting an access token is a >> new design pattern. I think it has value and should be included, but OAu= th >> today shows us the immense value of getting access tokens for calling AP= Is, >> and so we shouldn=E2=80=99t optimize away from that pattern. >> >> >> 5) If the AS does not provide an "access token", there is no mechanism >> for a client to delete the request, as the client is not allowed to make= a >> call without an "access token". >> >> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D f= ield then the >> client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99= s intentional. The AS is >> telling this client instance that it can=E2=80=99t do anything else with= this >> ongoing request. If the AS wants to allow the client to manage it, it wi= ll >> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. >> > > There is nuance in that intention. A related concern is that deleting a > request does not seem like it is a "continue" operation. > > >> >> >> 6) There is no standard identifier for the request. Debugging and >> auditing are hampered by the client and AS having no standard way to >> identifying a request. While one AS may provide a unique URL for each gr= ant >> request, another AS may use a persistent "access token" to identify the >> grant request, and other ASs may issue a new "access token" on each API >> call, providing no persistent identifier for the request. >> >> >> Debugging and auditing this kind of thing are functions of the AS. How i= s >> interoperability harmed by different ASs having different methods to >> identify their internal data elements? The client doesn=E2=80=99t need a= ny >> knowledge of the AS=E2=80=99s identifiers, it just needs to know the nex= t steps for >> continuing the negotiation. >> > > Debugging between the client and the AS was what I was referring to. How > does a client developer identify the request when communicating to the AS > developer. Seems complicated. > > =E1=90=A7 > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000008d5dde05b637706c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Even though I've only been lightly following= things, I feel the need to voice my preference as a developer since I will= probably someday have to either write a RC or RS...=C2=A0

The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
At this point that request, represente= d by the continue URL=C2=A0+ "Access Token", from my lazy develop= er standpoint, is a Resource Endpoint and Access Token, and the AS is actin= g as a specialized RS in this case.
So my client posts to whateve= r URL with the 'access token' in the authorization header, just lik= e acting on any other resource I have a token for. YES, I get a new token v= alue to use every call, and there is a decision point of "Do I have an= other continue, or do I have a real token for the resource..." But the= mechanism is the same to me in the client.
Personally I like tha= t, because if I have an access_token, I already think "Put it in the a= uth header."=C2=A0

So my vote would be=C2=A0+= 1 for the pull request at this time.
-steve

=
On Fri, De= c 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
inline ...=C2=A0
On = Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
Others had already responded t= o this previous thread, but I wanted to add a couple points to clarify some= things.

3) What the client has to d= o with the "access token" is not the same as access tokens for an= RS. The client gets a new "access token" for each grant request,= and for each API call to the AS, and the client learns it can not make any= more API calls for that specific request when it does not get an "acc= ess token" back. This is a completely different design pattern than ca= lling an RS API with an access token,=C2=A0and is a new design pattern for = calling APIs. This adds complexity to the client that it would not normally= have, and I don't think GNAP is the right place to start a new design = pattern.


I=E2=80=99m n= ot sure what you mean by these being different =E2=80=94 the whole point of= the design is that the client would be doing the same thing with the acces= s token at the AS that it does with the RS by re-using the access token str= ucture. Can you please describe what the differences are, apart from the ro= tation? Presentation of the token and signing of the message are identical.=

The client is getting th= e "access token" from its API. It is not using an "access_to= ken" in other API calls to the AS.
=C2=A0

Rotation= of the access token and artifacts for ongoing continuation responses is a = separate issue to be discussed:=C2=A0https://github.com/iet= f-wg-gnap/gnap-core-protocol/issues/87

And for= what it=E2=80=99s worth, GNAP is absolutely the right place to have new de= signs =E2=80=94 not that this is one.
You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me.
=C2=A0

4) Clients that only want claims from the AS and no access t= okens will be required to support an API calling mechanism they would not h= ave to support otherwise.=C2=A0

Corre= ct, but the delta between the calls a client would make with and without an= access token is vanishingly small. The client has to sign the initial requ= est in some fashion, and it will sign the continuation request in the same = exact fashion, but now include an access token in that request.=C2=A0
=

Per my other point, there is n= o value to me in my implementations of passing context back and forth betwe= en the client and AS -- so it is extra work providing no value.
<= br>
Also, any client authentication mechanism=C2=A0that wants to = use the HTTP Authentication header is precluded from using it.
=C2=A0
=

Clients making a request to an AS and not get= ting an access token is a new design pattern. I think it has value and shou= ld be included, but OAuth today shows us the immense value of getting acces= s tokens for calling APIs, and so we shouldn=E2=80=99t optimize away from t= hat pattern.


5) If t= he AS does not provide an "access token", there is no mechanism f= or a client to delete the request, as the client is not allowed to make a c= all without an "access token".

<= div>More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D = field then the client can=E2=80=99t delete the request =E2=80=94 and yes, t= hat=E2=80=99s intentional. The AS is telling this client instance that it c= an=E2=80=99t do anything else with this ongoing request. If the AS wants to= allow the client to manage it, it will include the mechanisms to do so in = the =E2=80=9Ccontinue=E2=80=9D field.
There is nuance in that intention. A related concern is that d= eleting a request does not seem like it is a "continue" operation= .
=C2=A0


6) There is = no standard identifier for the request. Debugging and auditing are hampered= by the client and AS having no standard way to identifying a request. Whil= e one AS may provide a unique URL for each grant request, another AS may us= e a persistent "access token" to identify the grant request, and = other ASs may=C2=A0issue a new "access token" on each API call, p= roviding no persistent identifier for the request.
<= br>
Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.

Debugging between the client and the AS was what I was referring to= . How does a client developer identify the request when communicating to th= e AS developer. Seems complicated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000008d5dde05b637706c-- From nobody Fri Dec 11 14:33:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7958E3A0FD9 for ; Fri, 11 Dec 2020 14:33:15 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgzJhCL4YMOJ for ; Fri, 11 Dec 2020 14:33:13 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 948903A0FD0 for ; Fri, 11 Dec 2020 14:33:12 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id a1so12721948ljq.3 for ; Fri, 11 Dec 2020 14:33:12 -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=IJpc+FlhlBws76To7IuoWdTEneuiYTVMPVzFkR2eQwI=; b=odnMhpSONVB9mHh7cKuJ3ooKPBzdGVfo/r01eYpGe3LOVWqx0b1bRthDP+AVezlU35 T2pIg9f1rawR1XSbfoq5hL2bVWukKG8uWFpWuVVtmY855jvEnD/F6Iv8GH8XfWlCMibq Xm3qrWBHLB8AM2aVFKwsXTGLuB7BD3h6aYtkKkUUfhOpG4DpVvnaLx8VcejjoNvlrKhK GOkzeqlHU10uaMA+AM+51MYT7P/uzWkKRX91GI5ca+sDI1kCEZuEogCLIb9Z5TbP1l3J HAH6PZO1f00aDzhSLp1V4GqsHYQNQn9axqeBBgNgYX8gW2VqV1atU7v7qqziI1AMKJlo eqEA== 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=IJpc+FlhlBws76To7IuoWdTEneuiYTVMPVzFkR2eQwI=; b=jTgUAlFeEzNw2//zahIkmh+YdpIC83TYaZem2uzuQKP6jnY/61SjVMJyPi1UonbXLq TKqzPo/YqxGccoKMhQ/NSVuGPkhaIBgRCJeDqQ9Goz+4pSrNxWyNH/zzkPYjVNszIuD4 bkGWFVoPMysEZhifiPfmXw+8kfh6adPp/nVRQMgQ9FAlmmUZkGBg7JoVyjBqYUnASwLS SDSesyRHiWFxuG2iz6N6bQQH7lojPcyUiL/QbItlLYkL02R5dFqM5FNwDhQv0zChG8qH +Vi0IJjYtIzWgUMyYdkXezk4Ux12LDuSMasslXudiLKxdf5SRNMCH66p/JTfKioNvOpG 2VKA== X-Gm-Message-State: AOAM530a4aHlWGfiOr6EH/drS2jr5LL2sNUjykRL+Gx7vMb/LaEaFlwW /hwppnhtKJyi612AfwzOVhz+LB69/K2KObWTiXk= X-Google-Smtp-Source: ABdhPJyNlO/qGBhcA2KOlVLxsVia8zHGoUMLgO4I9kUFvuTo91b3/A7pTc8ZYbbmX4h6u3z5v42NcLYzLKb14oJvSzI= X-Received: by 2002:a2e:7803:: with SMTP id t3mr3680824ljc.213.1607725990478; Fri, 11 Dec 2020 14:33:10 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 11 Dec 2020 14:32:34 -0800 Message-ID: To: Stephen Moore Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="0000000000008f097505b637e039" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 22:33:16 -0000 --0000000000008f097505b637e039 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stephen The client is signing the first request. The key *might* be in the body. The client is signing all the subsequent requests as well. The "access token" is not needed by the client to prove it is authorized as the client is proving it is the same client again. In other words, I don't see the need for an access token, so it does not need to be put in a URL or an auth header. If a developer really, really wants to hand context back to the client for subsequent calls, they can put it in the URL or some other method. Putting it in the HTTP Authorization header is confusing because it is NOT an access token -- it is the context of the request. =E1=90=A7 On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore wrote: > Even though I've only been lightly following things, I feel the need to > voice my preference as a developer since I will probably someday have to > either write a RC or RS... > > The way I see it is the RC makes the initial request to the AS as part of > this request, it provides it's key in the body... (So no use of the > Authorization header) > At this point that request, represented by the continue URL + "Access > Token", from my lazy developer standpoint, is a Resource Endpoint and > Access Token, and the AS is acting as a specialized RS in this case. > So my client posts to whatever URL with the 'access token' in the > authorization header, just like acting on any other resource I have a tok= en > for. YES, I get a new token value to use every call, and there is a > decision point of "Do I have another continue, or do I have a real token > for the resource..." But the mechanism is the same to me in the client. > Personally I like that, because if I have an access_token, I already thin= k > "Put it in the auth header." > > So my vote would be +1 for the pull request at this time. > -steve > > On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt wrote: > >> inline ... >> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote: >> >>> Others had already responded to this previous thread, but I wanted to >>> add a couple points to clarify some things. >>> >>> 3) What the client has to do with the "access token" is not the same as >>> access tokens for an RS. The client gets a new "access token" for each >>> grant request, and for each API call to the AS, and the client learns i= t >>> can not make any more API calls for that specific request when it does = not >>> get an "access token" back. This is a completely different design patte= rn >>> than calling an RS API with an access token, and is a new design patter= n >>> for calling APIs. This adds complexity to the client that it would not >>> normally have, and I don't think GNAP is the right place to start a new >>> design pattern. >>> >>> >>> I=E2=80=99m not sure what you mean by these being different =E2=80=94 t= he whole point of >>> the design is that the client would be doing the same thing with the ac= cess >>> token at the AS that it does with the RS by re-using the access token >>> structure. Can you please describe what the differences are, apart from= the >>> rotation? Presentation of the token and signing of the message are >>> identical. >>> >> >> The client is getting the "access token" from its API. It is not using a= n >> "access_token" in other API calls to the AS. >> >> >>> >>> Rotation of the access token and artifacts for ongoing continuation >>> responses is a separate issue to be discussed: >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>> >>> And for what it=E2=80=99s worth, GNAP is absolutely the right place to = have new >>> designs =E2=80=94 not that this is one. >>> >> >> You are proposing a new way for an API to provide context for subsequent >> API calls. Looks out of scope to me. >> >> >>> >>> 4) Clients that only want claims from the AS and no access tokens will >>> be required to support an API calling mechanism they would not have to >>> support otherwise. >>> >>> >>> Correct, but the delta between the calls a client would make with and >>> without an access token is vanishingly small. The client has to sign th= e >>> initial request in some fashion, and it will sign the continuation requ= est >>> in the same exact fashion, but now include an access token in that requ= est. >>> >> >> Per my other point, there is no value to me in my implementations of >> passing context back and forth between the client and AS -- so it is ext= ra >> work providing no value. >> >> Also, any client authentication mechanism that wants to use the HTTP >> Authentication header is precluded from using it. >> >> >> >>> >>> Clients making a request to an AS and not getting an access token is a >>> new design pattern. I think it has value and should be included, but OA= uth >>> today shows us the immense value of getting access tokens for calling A= PIs, >>> and so we shouldn=E2=80=99t optimize away from that pattern. >>> >>> >>> 5) If the AS does not provide an "access token", there is no mechanism >>> for a client to delete the request, as the client is not allowed to mak= e a >>> call without an "access token". >>> >>> >>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D = field then the >>> client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80= =99s intentional. The AS is >>> telling this client instance that it can=E2=80=99t do anything else wit= h this >>> ongoing request. If the AS wants to allow the client to manage it, it w= ill >>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field= . >>> >> >> There is nuance in that intention. A related concern is that deleting a >> request does not seem like it is a "continue" operation. >> >> >>> >>> >>> 6) There is no standard identifier for the request. Debugging and >>> auditing are hampered by the client and AS having no standard way to >>> identifying a request. While one AS may provide a unique URL for each g= rant >>> request, another AS may use a persistent "access token" to identify the >>> grant request, and other ASs may issue a new "access token" on each API >>> call, providing no persistent identifier for the request. >>> >>> >>> Debugging and auditing this kind of thing are functions of the AS. How >>> is interoperability harmed by different ASs having different methods to >>> identify their internal data elements? The client doesn=E2=80=99t need = any >>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the ne= xt steps for >>> continuing the negotiation. >>> >> >> Debugging between the client and the AS was what I was referring to. How >> does a client developer identify the request when communicating to the A= S >> developer. Seems complicated. >> >> =E1=90=A7 >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000008f097505b637e039 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephen

The client is signing the fi= rst request. The key *might* be in the body. The client is signing all the = subsequent requests as well. The "access token" is not needed by = the client to prove it is authorized as the client is proving it is the sam= e client again.

In other words, I don't see th= e need for an access token, so it does not need to be put in a URL or an au= th header.

If a developer really, really wants to = hand context back to the client for subsequent calls, they can put it in th= e URL or some other method. Putting it in the HTTP Authorization header is = confusing because it is NOT an access token -- it is the context of the req= uest.

3D""=E1=90=A7

On Fri, Dec 11, 20= 20 at 2:01 PM Stephen Moore <srmoor= e@gmail.com> wrote:
Even though I've only been lightl= y following things, I feel the need to voice my preference as a developer s= ince I will probably someday have to either write a RC or RS...=C2=A0
=

The way I see it is the RC makes the initial request to= the AS as part of this request, it provides it's key in the body... (S= o no use of the Authorization header)
At this point that request,= represented by the continue URL=C2=A0+ "Access Token", from my l= azy developer standpoint, is a Resource Endpoint and Access Token, and the = AS is acting as a specialized RS in this case.
So my client posts= to whatever URL with the 'access token' in the authorization heade= r, just like acting on any other resource I have a token for. YES, I get a = new token value to use every call, and there is a decision point of "D= o I have another continue, or do I have a real token for the resource...&qu= ot; But the mechanism is the same to me in the client.
Personally= I like that, because if I have an access_token, I already think "Put = it in the auth header."=C2=A0

So my vote woul= d be=C2=A0+1 for the pull request at this time.
-steve

On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
inline ...=C2=A0

On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <= ;jricher@mit.edu&g= t; wrote:
O= thers had already responded to this previous thread, but I wanted to add a = couple points to clarify some things.

3) What the client has to do with the "access token" is not the= same as access tokens for an RS. The client gets a new "access token&= quot; for each grant request, and for each API call to the AS, and the clie= nt learns it can not make any more API calls for that specific request when= it does not get an "access token" back. This is a completely dif= ferent design pattern than calling an RS API with an access token,=C2=A0and= is a new design pattern for calling APIs. This adds complexity to the clie= nt that it would not normally have, and I don't think GNAP is the right= place to start a new design pattern.


I=E2=80=99m not sure what you mean by these being different= =E2=80=94 the whole point of the design is that the client would be doing = the same thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the diffe= rences are, apart from the rotation? Presentation of the token and signing = of the message are identical.

=
The client is getting the "access token" from its API. It is= not using an "access_token" in other API calls to the AS.
<= div>=C2=A0

Rotation of the access token and artifacts for ongoing= continuation responses is a separate issue to be discussed:=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87

And for what it=E2=80=99s worth, GNAP is absolutely= the right place to have new designs =E2=80=94 not that this is one.
<= /div>

You are proposing a new way for= an API to provide context for subsequent API calls. Looks out of scope to = me.
=C2=A0

4) Clients that only want cla= ims from the AS and no access tokens will be required to support an API cal= ling mechanism they would not have to support otherwise.=C2=A0

Correct, but the delta between the calls a client= would make with and without an access token is vanishingly small. The clie= nt has to sign the initial request in some fashion, and it will sign the co= ntinuation request in the same exact fashion, but now include an access tok= en in that request.=C2=A0

Per my other point, there is no value to me in my implementations of passi= ng context back and forth between the client and AS -- so it is extra work = providing no value.

Also, any client authenticatio= n mechanism=C2=A0that wants to use the HTTP Authentication header is preclu= ded from using it.

=C2=A0

Clients maki= ng a request to an AS and not getting an access token is a new design patte= rn. I think it has value and should be included, but OAuth today shows us t= he immense value of getting access tokens for calling APIs, and so we shoul= dn=E2=80=99t optimize away from that pattern.


5) If the AS does not provide an "access tok= en", there is no mechanism for a client to delete the request, as the = client is not allowed to make a call without an "access token".

More properly, if the AS does not prov= ide a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2=80=99t delete= the request =E2=80=94 and yes, that=E2=80=99s intentional. The AS is telli= ng this client instance that it can=E2=80=99t do anything else with this on= going request. If the AS wants to allow the client to manage it, it will in= clude the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field.

There is nuance in that inten= tion. A related concern is that deleting a request does not seem like it is= a "continue" operation.
=C2=A0


6) There is no standard identifier for the request. De= bugging and auditing are hampered by the client and AS having no standard w= ay to identifying a request. While one AS may provide a unique URL for each= grant request, another AS may use a persistent "access token" to= identify the grant request, and other ASs may=C2=A0issue a new "acces= s token" on each API call, providing no persistent identifier for the = request.

Debugging and auditing this kind = of thing are functions of the AS. How is interoperability harmed by differe= nt ASs having different methods to identify their internal data elements? T= he client doesn=E2=80=99t need any knowledge of the AS=E2=80=99s identifier= s, it just needs to know the next steps for continuing the negotiation.

Debugging between the client and t= he AS was what I was referring to. How does a client developer identify the= request when communicating to the AS developer. Seems complicated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000008f097505b637e039-- From nobody Fri Dec 11 14:53:18 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5163A0FFB for ; Fri, 11 Dec 2020 14:53:15 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGlWTy6smQCt for ; Fri, 11 Dec 2020 14:53:13 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 195723A0FF1 for ; Fri, 11 Dec 2020 14:53:13 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id x2so9495487ybt.11 for ; Fri, 11 Dec 2020 14:53:13 -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=Kc4kvm9xhwf+QLO7B19FA0sYFHn4cNzj82wq/NY3MK0=; b=WzmKQ6KFsK6mfyRlhPLfDmaK1CbswL1xO87scpitlbj3Qc24Ai3iWmbFhBIPkl2JP7 H3hGpbEMB70dEgUbFnXYJVl8570y+YVu/smXrOpU7HRnTrl8ccO/c4kGlNhTsSE3UhAk 3sNY46UMzjuVjfahUyGyHOVtBhg178jQiXnJmegL+fDgOPY5H42/S6GUst0ZLK8NoKif GXKt9WGuWljLtZBrnQlezrHz+L3jK9O9uB3y2pOwXnjfACcU84aDufkPBlmfWsOiDUmZ H7xqmlvAasQlyA5TO6SE/Zxw7jW6j0DMyNAsZCP0pZKFlaeJ8WnjdiPCASjOYsCe8oDd +Bwg== 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=Kc4kvm9xhwf+QLO7B19FA0sYFHn4cNzj82wq/NY3MK0=; b=UO3h5/NdFrpIrdd+raKCcVTYK6LFZWdL8QJyDCuyquJOf6Kz7GYgfuVgOZBuVylX0Z COPr4v9IIpvm2RDtmwURlZDruZay7AZ8/Cfo48SsTdYO/3jtmh8OWuHEAEdXnYvGjw2t ezLHhr+ymtHjq/X+mRUk0iYl7Tl42riCqOHHAgj0iV5dpNHmPr8X6YxyPsrV100S+H88 NMvBuipB1AU5KyGp/rypJHubBfcyngP8rLuXcsf/fQ+r39cNJx6Pe+GRJa/M4g7aKeYB zX8RsrnY7jvR2Blz41uiLi6OJKycaJtRt9g4UKz2D5KHQnFilv51NbSzTP5UMR76aNCj s+yw== X-Gm-Message-State: AOAM533P842zNWgVV1nL7ajJMdLa1v6oQIH2WaulgeprlApAIu3coNL7 HkUo+G3PoSuExLZFzj81w5d2o9IZn7SOlEwixzk= X-Google-Smtp-Source: ABdhPJwMHOS4ugNlcW3jhrJKDPwZ2VmvhiDTvxgT0dRv/f2livSvziZgShEVUorSXyBNvrnkobijVkmkUdIEQqqdRGM= X-Received: by 2002:a25:d483:: with SMTP id m125mr8235298ybf.330.1607727192138; Fri, 11 Dec 2020 14:53:12 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Stephen Moore Date: Fri, 11 Dec 2020 17:53:01 -0500 Message-ID: To: Dick Hardt Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="0000000000002ee7a205b63828e0" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 22:53:16 -0000 --0000000000002ee7a205b63828e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But from the spec: " When sending a non-continuation request to the AS, the RC MUST identify itself by including the client field of the request... ... key (object / string) : The public key of the RC to be used in this request as described in {{request-key}}. This field is REQUIRED. ... " So on the initial request, the key will be there. If you don't have the access token, then how do you differentiate between two requests from the same web application by two different users? Is the web application supposed to have different credentials for every request? So in this case, the easy way out is to pass the access token to the client, who then, as i stated before, treats the continue request as a RS call (albeit a specialized version of the RS where the RS is the AS) OR to use the unique URL, but that seems open to a brute force attack by a malicious RC. (What would be the point of that attack, I don't know, I guess if someone had the client credentials but not any subjects/resources they could try to intercept the grant via continue... I just don't feel right locking things down to unique URLs that way.) -steve On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt wrote: > Hi Stephen > > The client is signing the first request. The key *might* be in the body. > The client is signing all the subsequent requests as well. The "access > token" is not needed by the client to prove it is authorized as the clien= t > is proving it is the same client again. > > In other words, I don't see the need for an access token, so it does not > need to be put in a URL or an auth header. > > If a developer really, really wants to hand context back to the client fo= r > subsequent calls, they can put it in the URL or some other method. Puttin= g > it in the HTTP Authorization header is confusing because it is NOT an > access token -- it is the context of the request. > > =E1=90=A7 > > On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore wrote: > >> Even though I've only been lightly following things, I feel the need to >> voice my preference as a developer since I will probably someday have to >> either write a RC or RS... >> >> The way I see it is the RC makes the initial request to the AS as part o= f >> this request, it provides it's key in the body... (So no use of the >> Authorization header) >> At this point that request, represented by the continue URL + "Access >> Token", from my lazy developer standpoint, is a Resource Endpoint and >> Access Token, and the AS is acting as a specialized RS in this case. >> So my client posts to whatever URL with the 'access token' in the >> authorization header, just like acting on any other resource I have a to= ken >> for. YES, I get a new token value to use every call, and there is a >> decision point of "Do I have another continue, or do I have a real token >> for the resource..." But the mechanism is the same to me in the client. >> Personally I like that, because if I have an access_token, I already >> think "Put it in the auth header." >> >> So my vote would be +1 for the pull request at this time. >> -steve >> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt wrote: >> >>> inline ... >>> >>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote: >>> >>>> Others had already responded to this previous thread, but I wanted to >>>> add a couple points to clarify some things. >>>> >>>> 3) What the client has to do with the "access token" is not the same a= s >>>> access tokens for an RS. The client gets a new "access token" for each >>>> grant request, and for each API call to the AS, and the client learns = it >>>> can not make any more API calls for that specific request when it does= not >>>> get an "access token" back. This is a completely different design patt= ern >>>> than calling an RS API with an access token, and is a new design patte= rn >>>> for calling APIs. This adds complexity to the client that it would not >>>> normally have, and I don't think GNAP is the right place to start a ne= w >>>> design pattern. >>>> >>>> >>>> I=E2=80=99m not sure what you mean by these being different =E2=80=94 = the whole point >>>> of the design is that the client would be doing the same thing with th= e >>>> access token at the AS that it does with the RS by re-using the access >>>> token structure. Can you please describe what the differences are, apa= rt >>>> from the rotation? Presentation of the token and signing of the messag= e are >>>> identical. >>>> >>> >>> The client is getting the "access token" from its API. It is not using >>> an "access_token" in other API calls to the AS. >>> >>> >>>> >>>> Rotation of the access token and artifacts for ongoing continuation >>>> responses is a separate issue to be discussed: >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>> >>>> And for what it=E2=80=99s worth, GNAP is absolutely the right place to= have new >>>> designs =E2=80=94 not that this is one. >>>> >>> >>> You are proposing a new way for an API to provide context for subsequen= t >>> API calls. Looks out of scope to me. >>> >>> >>>> >>>> 4) Clients that only want claims from the AS and no access tokens will >>>> be required to support an API calling mechanism they would not have to >>>> support otherwise. >>>> >>>> >>>> Correct, but the delta between the calls a client would make with and >>>> without an access token is vanishingly small. The client has to sign t= he >>>> initial request in some fashion, and it will sign the continuation req= uest >>>> in the same exact fashion, but now include an access token in that req= uest. >>>> >>> >>> Per my other point, there is no value to me in my implementations of >>> passing context back and forth between the client and AS -- so it is ex= tra >>> work providing no value. >>> >>> Also, any client authentication mechanism that wants to use the HTTP >>> Authentication header is precluded from using it. >>> >>> >>> >>>> >>>> Clients making a request to an AS and not getting an access token is a >>>> new design pattern. I think it has value and should be included, but O= Auth >>>> today shows us the immense value of getting access tokens for calling = APIs, >>>> and so we shouldn=E2=80=99t optimize away from that pattern. >>>> >>>> >>>> 5) If the AS does not provide an "access token", there is no mechanism >>>> for a client to delete the request, as the client is not allowed to ma= ke a >>>> call without an "access token". >>>> >>>> >>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D= field then the >>>> client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80= =99s intentional. The AS is >>>> telling this client instance that it can=E2=80=99t do anything else wi= th this >>>> ongoing request. If the AS wants to allow the client to manage it, it = will >>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fiel= d. >>>> >>> >>> There is nuance in that intention. A related concern is that deleting a >>> request does not seem like it is a "continue" operation. >>> >>> >>>> >>>> >>>> 6) There is no standard identifier for the request. Debugging and >>>> auditing are hampered by the client and AS having no standard way to >>>> identifying a request. While one AS may provide a unique URL for each = grant >>>> request, another AS may use a persistent "access token" to identify th= e >>>> grant request, and other ASs may issue a new "access token" on each AP= I >>>> call, providing no persistent identifier for the request. >>>> >>>> >>>> Debugging and auditing this kind of thing are functions of the AS. How >>>> is interoperability harmed by different ASs having different methods t= o >>>> identify their internal data elements? The client doesn=E2=80=99t need= any >>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the n= ext steps for >>>> continuing the negotiation. >>>> >>> >>> Debugging between the client and the AS was what I was referring to. Ho= w >>> does a client developer identify the request when communicating to the = AS >>> developer. Seems complicated. >>> >>> =E1=90=A7 >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --0000000000002ee7a205b63828e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But from the spec:
"
When sending a non-continuation request to= the AS, the RC MUST identify itself by including the=C2=A0client=C2=A0field of the request...
...
key (object / string)= : The public key of the RC to be used in this request as described in {{re= quest-key}}. This field is REQUIRED.=C2=A0
...
&= quot;

So on the initial request, the key will be t= here.=C2=A0
If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
So in this case, the easy way out is to pass the access= token to the client, who then, as i stated before, treats the continue req= uest as a RS call (albeit=C2=A0a specialized=C2=A0version of the RS where t= he RS is the AS) OR to use the unique URL,=C2=A0
but that seems o= pen to a brute force attack by a malicious RC. (What would be the point of = that attack, I don't know, I guess if someone had the client credential= s but not any subjects/resources they could try to intercept the grant via = continue... I just don't feel right locking things down to unique URLs = that way.)
-steve

On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt= <dick.hardt@gmail.com> w= rote:
Hi Stephen

The client is signing the first requ= est. The key *might* be in the body. The client is signing all the subseque= nt requests as well. The "access token" is not needed by the clie= nt to prove it is authorized as the client is proving it is the same client= again.

In other words, I don't see the need f= or an access token, so it does not need to be put in a URL or an auth heade= r.

If a developer really, really wants to hand con= text back to the client for subsequent calls, they can put it in the URL or= some other method. Putting it in the HTTP Authorization header is confusin= g because it is NOT an access token -- it is the context of the request.

3D""=E1=90=A7

On Fri, Dec 11, 2020= at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
Even though I'v= e only been lightly following things, I feel the need to voice my preferenc= e as a developer since I will probably someday have to either write a RC or= RS...=C2=A0

The way I see it is the RC makes the = initial request to the AS as part of this request, it provides it's key= in the body... (So no use of the Authorization header)
At this p= oint that request, represented by the continue URL=C2=A0+ "Access Toke= n", from my lazy developer standpoint, is a Resource Endpoint and Acce= ss Token, and the AS is acting as a specialized RS in this case.
= So my client posts to whatever URL with the 'access token' in the a= uthorization header, just like acting on any other resource I have a token = for. YES, I get a new token value to use every call, and there is a decisio= n point of "Do I have another continue, or do I have a real token for = the resource..." But the mechanism is the same to me in the client.
Personally I like that, because if I have an access_token, I alread= y think "Put it in the auth header."=C2=A0

So my vote would be=C2=A0+1 for the pull request at this time.
-steve

On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com= > wrote:
inline ...=C2=A0

On Fri, Dec 11, 2020 at 9:58 = AM Justin Richer <j= richer@mit.edu> wrote:
Others had already responded to this previous thread, bu= t I wanted to add a couple points to clarify some things.

3) What the client has to do with the "access to= ken" is not the same as access tokens for an RS. The client gets a new= "access token" for each grant request, and for each API call to = the AS, and the client learns it can not make any more API calls for that s= pecific request when it does not get an "access token" back. This= is a completely different design pattern than calling an RS API with an ac= cess token,=C2=A0and is a new design pattern for calling APIs. This adds co= mplexity to the client that it would not normally have, and I don't thi= nk GNAP is the right place to start a new design pattern.


I=E2=80=99m not sure what you mean by t= hese being different =E2=80=94 the whole point of the design is that the cl= ient would be doing the same thing with the access token at the AS that it = does with the RS by re-using the access token structure. Can you please des= cribe what the differences are, apart from the rotation? Presentation of th= e token and signing of the message are identical.

The client is getting the "access token"= from its API. It is not using an "access_token" in other API cal= ls to the AS.
=C2=A0

Rotation of the access token and a= rtifacts for ongoing continuation responses is a separate issue to be discu= ssed:=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/issues/87

And for what it=E2=80=99s worth, = GNAP is absolutely the right place to have new designs =E2=80=94 not that t= his is one.

You are propo= sing a new way for an API to provide context for subsequent API calls. Look= s out of scope to me.
=C2=A0

4) Clients = that only want claims from the AS and no access tokens will be required to = support an API calling mechanism they would not have to support otherwise.= =C2=A0

Correct, but the delta between= the calls a client would make with and without an access token is vanishin= gly small. The client has to sign the initial request in some fashion, and = it will sign the continuation request in the same exact fashion, but now in= clude an access token in that request.=C2=A0
=

Per my other point, there is no value to me in my imple= mentations of passing context back and forth between the client and AS -- s= o it is extra work providing no value.

Also, any c= lient authentication mechanism=C2=A0that wants to use the HTTP Authenticati= on header is precluded from using it.

=C2=A0
=

=
Clients making a request to an AS and not getting an access token is a= new design pattern. I think it has value and should be included, but OAuth= today shows us the immense value of getting access tokens for calling APIs= , and so we shouldn=E2=80=99t optimize away from that pattern.


5) If the AS does not provide an= "access token", there is no mechanism for a client to delete the= request, as the client is not allowed to make a call without an "acce= ss token".

More properly, if the= AS does not provide a =E2=80=9Ccontinue=E2=80=9D field then the client can= =E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99s intentional= . The AS is telling this client instance that it can=E2=80=99t do anything = else with this ongoing request. If the AS wants to allow the client to mana= ge it, it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2= =80=9D field.

There is nu= ance in that intention. A related concern is that deleting a request does n= ot seem like it is a "continue" operation.
=C2=A0


6) There is no standard identifier f= or the request. Debugging and auditing are hampered by the client and AS ha= ving no standard way to identifying a request. While one AS may provide a u= nique URL for each grant request, another AS may use a persistent "acc= ess token" to identify the grant request, and other ASs may=C2=A0issue= a new "access token" on each API call, providing no persistent i= dentifier for the request.

Debugging and a= uditing this kind of thing are functions of the AS. How is interoperability= harmed by different ASs having different methods to identify their interna= l data elements? The client doesn=E2=80=99t need any knowledge of the AS=E2= =80=99s identifiers, it just needs to know the next steps for continuing th= e negotiation.

Debugging betwee= n the client and the AS was what I was referring to. How does a client deve= loper identify the request when communicating to the AS developer. Seems co= mplicated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000002ee7a205b63828e0-- From nobody Fri Dec 11 15:35:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AA03A1034 for ; Fri, 11 Dec 2020 15:34:58 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee5R58tiT860 for ; Fri, 11 Dec 2020 15:34:56 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF573A1033 for ; Fri, 11 Dec 2020 15:34:55 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id m12so15628498lfo.7 for ; Fri, 11 Dec 2020 15:34:54 -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=itlyyY74cIsndXNAvzQYuR41t8/NKg4L94BtDvECJAY=; b=HI/VMBOKMYHmy2X3Bse4OmRyHbo2/LAC77pZlHIWyMvCOW7JYpHoHl62aZGD26Q/GV NdazmYGKZxCoGGHHP4R5z0lKLAV6tJuqa8X6D62J9rMe8w6f9/jGZhSPJBqF6hazVzIL uEdDRiPDXJVe7FFj/Wf8FgiJGBlOA9BUqk0jcVlfDPQHKhy50/3KEALI1FS9DiBuPsn5 eHnaUGw74o6LHaBOF+dZlW7HnnesU9hJlkdXe1EI5e8h58fHASIkXlzkKiL3g8XepP6J 8VbMDMD25krS2CJeTCmxlG+zvt25tOamSWMVYrHChw4pHdlUpXWgSoO2Ae6aprgVHFhS 3yPQ== 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=itlyyY74cIsndXNAvzQYuR41t8/NKg4L94BtDvECJAY=; b=q4Su2hr+jXWFr5NDwBqw7RYLdwPT8x/vtFhKpXUWIZZxOx5sgDOg0GRo5KuGaOaGcb 7S1gB3Q7i0yD1e0l3VsvWjTcZoWB5hH9SdIjLAaJcLNV9VvLKeLfYn1FVbag23Z6CvMI VVOtDglt7VcViLwNnG04eMTx7gDD7ixCWJeouuxTitDif7/+H7WgmvvvzSLE+3YHRC+p 5+0Seru4wNkXy15uR0Kg6qiDKv+1Txhy5yAbLmG+Gshaj2ZjA5kZrW85RCfGXXtjnUhD NXb4M9yoMc6NSKxHyRwC4sIDz+e2k3GepSLGdr5t5uVYYln8gNkYoGYJ4Tn7dnZV4jzP CMgw== X-Gm-Message-State: AOAM532ZW8ZK9ribIUcC8DCPggDZQH67IBPmVRDMU2ZOJmtFKaf5+u0G jJJz2I+ZkAkOZE8qWX31ZCO7iSb2fHkRrgkwsrI= X-Google-Smtp-Source: ABdhPJwfCtaVC6eFiohjBTydwxBbdF/E9fHJDyJfunSTa1OYHTQoYwM3ijQ+3rdV8wU3knzQ67ywydtpfKlWCRrz/rc= X-Received: by 2002:a19:3818:: with SMTP id f24mr3178514lfa.89.1607729688038; Fri, 11 Dec 2020 15:34:48 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 11 Dec 2020 15:34:11 -0800 Message-ID: To: Stephen Moore Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="000000000000f352d405b638bc40" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 11 Dec 2020 23:34:58 -0000 --000000000000f352d405b638bc40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore wrote: > But from the spec: > " > When sending a non-continuation request to the AS, the RC MUST identify > itself by including the client field of the request... > ... > key (object / string) : The public key of the RC to be used in this > request as described in {{request-key}}. This field is REQUIRED. > ... > " > So on the initial request, the key will be there. > The client field can be an object or a string. If the client is pre-registered, then a string could be provided instead of an object. > > > If you don't have the access token, then how do you differentiate between > two requests from the same web application by two different users? Is the > web application supposed to have different credentials for every request? > The AS returns a URI for manipulating the request. I would change the spec so that each request would have a unique URI. This is the usually RESTful pattern that the resource (the grant request) has an URI. > So in this case, the easy way out is to pass the access token to the > client, who then, as i stated before, treats the continue request as a RS > call (albeit a specialized version of the RS where the RS is the AS) OR t= o > use the unique URL, > but that seems open to a brute force attack by a malicious RC. (What woul= d > be the point of that attack, I don't know, I guess if someone had the > client credentials but not any subjects/resources they could try to > intercept the grant via continue... I just don't feel right locking thing= s > down to unique URLs that way.) > If someone has the client credentials, they can impersonate the client, and all bets are off. LOTS of RS servers return a resource specific URL -- my proposal is no different. > -steve > > On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt wrote: > >> Hi Stephen >> >> The client is signing the first request. The key *might* be in the body. >> The client is signing all the subsequent requests as well. The "access >> token" is not needed by the client to prove it is authorized as the clie= nt >> is proving it is the same client again. >> >> In other words, I don't see the need for an access token, so it does not >> need to be put in a URL or an auth header. >> >> If a developer really, really wants to hand context back to the client >> for subsequent calls, they can put it in the URL or some other method. >> Putting it in the HTTP Authorization header is confusing because it is N= OT >> an access token -- it is the context of the request. >> >> =E1=90=A7 >> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore wrote: >> >>> Even though I've only been lightly following things, I feel the need to >>> voice my preference as a developer since I will probably someday have t= o >>> either write a RC or RS... >>> >>> The way I see it is the RC makes the initial request to the AS as part >>> of this request, it provides it's key in the body... (So no use of the >>> Authorization header) >>> At this point that request, represented by the continue URL + "Access >>> Token", from my lazy developer standpoint, is a Resource Endpoint and >>> Access Token, and the AS is acting as a specialized RS in this case. >>> So my client posts to whatever URL with the 'access token' in the >>> authorization header, just like acting on any other resource I have a t= oken >>> for. YES, I get a new token value to use every call, and there is a >>> decision point of "Do I have another continue, or do I have a real toke= n >>> for the resource..." But the mechanism is the same to me in the client. >>> Personally I like that, because if I have an access_token, I already >>> think "Put it in the auth header." >>> >>> So my vote would be +1 for the pull request at this time. >>> -steve >>> >>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt wrote= : >>> >>>> inline ... >>>> >>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote: >>>> >>>>> Others had already responded to this previous thread, but I wanted to >>>>> add a couple points to clarify some things. >>>>> >>>>> 3) What the client has to do with the "access token" is not the same >>>>> as access tokens for an RS. The client gets a new "access token" for = each >>>>> grant request, and for each API call to the AS, and the client learns= it >>>>> can not make any more API calls for that specific request when it doe= s not >>>>> get an "access token" back. This is a completely different design pat= tern >>>>> than calling an RS API with an access token, and is a new design patt= ern >>>>> for calling APIs. This adds complexity to the client that it would no= t >>>>> normally have, and I don't think GNAP is the right place to start a n= ew >>>>> design pattern. >>>>> >>>>> >>>>> I=E2=80=99m not sure what you mean by these being different =E2=80=94= the whole point >>>>> of the design is that the client would be doing the same thing with t= he >>>>> access token at the AS that it does with the RS by re-using the acces= s >>>>> token structure. Can you please describe what the differences are, ap= art >>>>> from the rotation? Presentation of the token and signing of the messa= ge are >>>>> identical. >>>>> >>>> >>>> The client is getting the "access token" from its API. It is not using >>>> an "access_token" in other API calls to the AS. >>>> >>>> >>>>> >>>>> Rotation of the access token and artifacts for ongoing continuation >>>>> responses is a separate issue to be discussed: >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>> >>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right place t= o have >>>>> new designs =E2=80=94 not that this is one. >>>>> >>>> >>>> You are proposing a new way for an API to provide context for >>>> subsequent API calls. Looks out of scope to me. >>>> >>>> >>>>> >>>>> 4) Clients that only want claims from the AS and no access tokens wil= l >>>>> be required to support an API calling mechanism they would not have t= o >>>>> support otherwise. >>>>> >>>>> >>>>> Correct, but the delta between the calls a client would make with and >>>>> without an access token is vanishingly small. The client has to sign = the >>>>> initial request in some fashion, and it will sign the continuation re= quest >>>>> in the same exact fashion, but now include an access token in that re= quest. >>>>> >>>> >>>> Per my other point, there is no value to me in my implementations of >>>> passing context back and forth between the client and AS -- so it is e= xtra >>>> work providing no value. >>>> >>>> Also, any client authentication mechanism that wants to use the HTTP >>>> Authentication header is precluded from using it. >>>> >>>> >>>> >>>>> >>>>> Clients making a request to an AS and not getting an access token is = a >>>>> new design pattern. I think it has value and should be included, but = OAuth >>>>> today shows us the immense value of getting access tokens for calling= APIs, >>>>> and so we shouldn=E2=80=99t optimize away from that pattern. >>>>> >>>>> >>>>> 5) If the AS does not provide an "access token", there is no mechanis= m >>>>> for a client to delete the request, as the client is not allowed to m= ake a >>>>> call without an "access token". >>>>> >>>>> >>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the >>>>> client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80= =99s intentional. The AS is >>>>> telling this client instance that it can=E2=80=99t do anything else w= ith this >>>>> ongoing request. If the AS wants to allow the client to manage it, it= will >>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fie= ld. >>>>> >>>> >>>> There is nuance in that intention. A related concern is that deleting = a >>>> request does not seem like it is a "continue" operation. >>>> >>>> >>>>> >>>>> >>>>> 6) There is no standard identifier for the request. Debugging and >>>>> auditing are hampered by the client and AS having no standard way to >>>>> identifying a request. While one AS may provide a unique URL for each= grant >>>>> request, another AS may use a persistent "access token" to identify t= he >>>>> grant request, and other ASs may issue a new "access token" on each A= PI >>>>> call, providing no persistent identifier for the request. >>>>> >>>>> >>>>> Debugging and auditing this kind of thing are functions of the AS. Ho= w >>>>> is interoperability harmed by different ASs having different methods = to >>>>> identify their internal data elements? The client doesn=E2=80=99t nee= d any >>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the = next steps for >>>>> continuing the negotiation. >>>>> >>>> >>>> Debugging between the client and the AS was what I was referring to. >>>> How does a client developer identify the request when communicating to= the >>>> AS developer. Seems complicated. >>>> >>>> =E1=90=A7 >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> =E1=90=A7 --000000000000f352d405b638bc40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 11, 2020 at 2:53 PM Steph= en Moore <srmoore@gmail.com>= wrote:
But from the spec:
"
When sending a non-continuation request to the AS,= the RC MUST identify itself by including the=C2=A0client=C2=A0field of the request...
...
key (object / string) : The p= ublic key of the RC to be used in this request as described in {{request-ke= y}}. This field is REQUIRED.=C2=A0
...
"
So on the initial request, the key will be there.= =C2=A0

The cli= ent field can be an object or a string. If the client is pre-registered, th= en a string could be provided instead of an object.
=C2=A0

<= /span>
If you don't have the access token, then how do you di= fferentiate between two requests from the same web application by two diffe= rent users? Is the web application supposed to have different credentials f= or every request?

The AS return= s=C2=A0a URI for manipulating the request. I would change the spec so that = each request would have a unique URI. This is the usually RESTful=C2=A0patt= ern that the resource (the grant request) has an URI.

<= div>=C2=A0
So in this case, the easy way out is to pass the access to= ken to the client, who then, as i stated before, treats the continue reques= t as a RS call (albeit=C2=A0a specialized=C2=A0version of the RS where the = RS is the AS) OR to use the unique URL,=C2=A0
but that seems open= to a brute force attack by a malicious RC. (What would be the point of tha= t attack, I don't know, I guess if someone had the client credentials b= ut not any subjects/resources they could try to intercept the grant via con= tinue... I just don't feel right locking things down to unique URLs tha= t way.)

If someone has the clie= nt credentials, they can impersonate=C2=A0the client, and all bets are off.=

LOTS of RS servers return a resource specific URL= -- my proposal is no different.


= =C2=A0
-steve

On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com= > wrote:
Hi Stephen

The client is signing the first = request. The key *might* be in the body. The client is signing all the subs= equent requests as well. The "access token" is not needed by the = client to prove it is authorized as the client is proving it is the same cl= ient again.

In other words, I don't see the ne= ed for an access token, so it does not need to be put in a URL or an auth h= eader.

If a developer really, really wants to hand= context back to the client for subsequent calls, they can put it in the UR= L or some other method. Putting it in the HTTP Authorization header is conf= using because it is NOT an access token -- it is the context of the request= .

3D""=E1=90=A7

On Fri, Dec 11, = 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
Even though I&#= 39;ve only been lightly following things, I feel the need to voice my prefe= rence as a developer since I will probably someday have to either write a R= C or RS...=C2=A0

The way I see it is the RC makes = the initial request to the AS as part of this request, it provides it's= key in the body... (So no use of the Authorization header)
At th= is point that request, represented by the continue URL=C2=A0+ "Access = Token", from my lazy developer standpoint, is a Resource Endpoint and = Access Token, and the AS is acting as a specialized RS in this case.
<= div>So my client posts to whatever URL with the 'access token' in t= he authorization header, just like acting on any other resource I have a to= ken for. YES, I get a new token value to use every call, and there is a dec= ision point of "Do I have another continue, or do I have a real token = for the resource..." But the mechanism is the same to me in the client= .
Personally I like that, because if I have an access_token, I al= ready think "Put it in the auth header."=C2=A0

So my vote would be=C2=A0+1 for the pull request at this time.
=
-steve

On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
inline ...=C2=A0

On Fri, Dec 11, 2020 at 9:5= 8 AM Justin Richer <jricher@mit.edu> wrote:
Others had already responded to this previous thread, = but I wanted to add a couple points to clarify some things.

3) What the client has to do with the "access = token" is not the same as access tokens for an RS. The client gets a n= ew "access token" for each grant request, and for each API call t= o the AS, and the client learns it can not make any more API calls for that= specific request when it does not get an "access token" back. Th= is is a completely different design pattern than calling an RS API with an = access token,=C2=A0and is a new design pattern for calling APIs. This adds = complexity to the client that it would not normally have, and I don't t= hink GNAP is the right place to start a new design pattern.

<= /div>

I=E2=80=99m not sure what you mean by= these being different =E2=80=94 the whole point of the design is that the = client would be doing the same thing with the access token at the AS that i= t does with the RS by re-using the access token structure. Can you please d= escribe what the differences are, apart from the rotation? Presentation of = the token and signing of the message are identical.

The client is getting the "access token&quo= t; from its API. It is not using an "access_token" in other API c= alls to the AS.
=C2=A0

Rotation of the access token and= artifacts for ongoing continuation responses is a separate issue to be dis= cussed:=C2=A0https://github.com/ietf-wg-gnap/gnap-core-prot= ocol/issues/87

And for what it=E2=80=99s worth= , GNAP is absolutely the right place to have new designs =E2=80=94 not that= this is one.

You are pro= posing a new way for an API to provide context for subsequent API calls. Lo= oks out of scope to me.
=C2=A0

4) Client= s that only want claims from the AS and no access tokens will be required t= o support an API calling mechanism they would not have to support otherwise= .=C2=A0

Correct, but the delta betwee= n the calls a client would make with and without an access token is vanishi= ngly small. The client has to sign the initial request in some fashion, and= it will sign the continuation request in the same exact fashion, but now i= nclude an access token in that request.=C2=A0

Per my other point, there is no value to me in my impl= ementations of passing context back and forth between the client and AS -- = so it is extra work providing no value.

Also, any = client authentication mechanism=C2=A0that wants to use the HTTP Authenticat= ion header is precluded from using it.

=C2=A0

Clients making a request to an AS and not getting an access token is = a new design pattern. I think it has value and should be included, but OAut= h today shows us the immense value of getting access tokens for calling API= s, and so we shouldn=E2=80=99t optimize away from that pattern.


5) If the AS does not provide a= n "access token", there is no mechanism for a client to delete th= e request, as the client is not allowed to make a call without an "acc= ess token".

More properly, if th= e AS does not provide a =E2=80=9Ccontinue=E2=80=9D field then the client ca= n=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99s intentiona= l. The AS is telling this client instance that it can=E2=80=99t do anything= else with this ongoing request. If the AS wants to allow the client to man= age it, it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2= =80=9D field.

There is nu= ance in that intention. A related concern is that deleting a request does n= ot seem like it is a "continue" operation.
=C2=A0


6) There is no standard identifier f= or the request. Debugging and auditing are hampered by the client and AS ha= ving no standard way to identifying a request. While one AS may provide a u= nique URL for each grant request, another AS may use a persistent "acc= ess token" to identify the grant request, and other ASs may=C2=A0issue= a new "access token" on each API call, providing no persistent i= dentifier for the request.

Debugging and a= uditing this kind of thing are functions of the AS. How is interoperability= harmed by different ASs having different methods to identify their interna= l data elements? The client doesn=E2=80=99t need any knowledge of the AS=E2= =80=99s identifiers, it just needs to know the next steps for continuing th= e negotiation.

Debugging betwee= n the client and the AS was what I was referring to. How does a client deve= loper identify the request when communicating to the AS developer. Seems co= mplicated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""= =E1=90=A7
--000000000000f352d405b638bc40-- From nobody Fri Dec 11 17:51:52 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2A3A0D17 for ; Fri, 11 Dec 2020 17:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 VujuqkH_DLaC for ; Fri, 11 Dec 2020 17:51:48 -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 077BD3A0D09 for ; Fri, 11 Dec 2020 17:51:48 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id y5so11432894iow.5 for ; Fri, 11 Dec 2020 17:51:47 -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=7ZtrOAA3DUjOeJSjUcaeQi6Zb+1rE+xEhFzg1yhHezs=; b=HS90O3O6K9Esv4+3Lns9s1DGztr34Uvif0NZi7AyqK00VC7yIHq9kUImC/ESkUJsCT WHmZ/fOMNEUsF/POzhETRSRKoLZ2wPm8NFk5aiXL9C3ERq4jn/HdN+vlhMf1Eda0Zf+8 rIll3h9o0GUMY1wpCUpOuj8zwaPkF/ml8NcBOeKtVApk3+b+WTuCrWZWDL5fXwvg0UHN aPvPYkD0kY2WPyb84GSHZB4I14zaxm50nsFfLxDBr7wLyeELSi6zkLtXOJjrtgxFvgv3 gDjt5sBep3HD499xkH7t316FIEWL84KWkIljJEYsS93P42DH4pkkEdjR5dLqlBzCZqpP hi2g== 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=7ZtrOAA3DUjOeJSjUcaeQi6Zb+1rE+xEhFzg1yhHezs=; b=DhhS2ncU/SQ0t3LHyl71VTYrPYPeurXDbPi2u7TCIEM+Q/PzkVfM1PC7KJPb3KIIjK bLQb7wKEEYDuTRVm5tv2liO4zkzKbUwx45PlRg/tadTSeV8VycAgdv0JyKR3AJC5GzFq xovqiHX9+Ostk4uZfWXiRPnDWInfz8SvRLefYweA2ZTMYzxd/6KKNT0pn3L6pfvvSrZJ 7R75jwsduWnYAh8Nn0mz18S9fQtybnudiPOSBiMQmeI3UznBUXz63Jjt2Y3+cn3NZWxo SIUVmQn1vrqo1PljkwROePuN0TaMrJfk3hiFtQmJIookm2TG2Y9xxvsR5+iRQVI7WNn6 xfGg== X-Gm-Message-State: AOAM531QX831UnvLbAxR5DYFitcCC6b8IOxjXvzN3QfaYSVzJuSqx3Mf 0aiJRaP/J39s1/71Qc2fGXUEtOdZztc2knblLzw= X-Google-Smtp-Source: ABdhPJy0XhisWjOalvRH1OgXd/mQflLx5/wIHtDlTiAA3MSpHlhyDtUSL5FAJbGsx41s15fstJvsrD8gEXaUT3I1ejc= X-Received: by 2002:a5d:85c7:: with SMTP id e7mr18707517ios.162.1607737907110; Fri, 11 Dec 2020 17:51:47 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Fabien Imbault Date: Sat, 12 Dec 2020 02:51:33 +0100 Message-ID: To: Dick Hardt Cc: Stephen Moore , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="000000000000d86a5605b63aa6ca" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 01:51:51 -0000 --000000000000d86a5605b63aa6ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Again speaking in my own name here. Dick, we know you'd prefer to have a different design, but this PR shouldn't be about that. Back on your 3 items : 1) yes we could make pre-register mandatory, but we already decided that wouldn't be how that would work. We have a client instance that allows a more generic and flexible pattern (which BTW also allows what you want) 2) instead of blame arguments of who's less restful/HATEOAS/whatever that have the tenancy to flame conversations, I suggest we speak in less abstract terms and ask ourselves what that means in practice for devs. Stephen and several others (myself included) have expressed that it wouldn't be harder to implement, it would even simplify things quite a lot. If you disagree please send us a code sample to really show that point by example, because that's really not obvious. 3) "If someone has the client credentials, they can impersonate the client, and all bets are off." Are you seriously making this argument? Because if you have a better proposal than using cryptographic keys, I'm all hears. You make it look like there's a problem, while in reality we're only relying on the basic assumption of all modern digital communications. And more importantly you never responded to the issues of how to avoid the security pitfalls of what you proposed. Fabien Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a= =C3=A9crit : > > > On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore wrote: > >> But from the spec: >> " >> When sending a non-continuation request to the AS, the RC MUST identify >> itself by including the client field of the request... >> ... >> key (object / string) : The public key of the RC to be used in this >> request as described in {{request-key}}. This field is REQUIRED. >> ... >> " >> > So on the initial request, the key will be there. >> > > The client field can be an object or a string. If the client is > pre-registered, then a string could be provided instead of an object. > >> > >> >> If you don't have the access token, then how do you differentiate betwee= n >> two requests from the same web application by two different users? Is th= e >> web application supposed to have different credentials for every request= ? >> > > The AS returns a URI for manipulating the request. I would change the spe= c > so that each request would have a unique URI. This is the usually > RESTful pattern that the resource (the grant request) has an URI. > > > >> So in this case, the easy way out is to pass the access token to the >> client, who then, as i stated before, treats the continue request as a R= S >> call (albeit a specialized version of the RS where the RS is the AS) OR = to >> use the unique URL, >> but that seems open to a brute force attack by a malicious RC. (What >> would be the point of that attack, I don't know, I guess if someone had = the >> client credentials but not any subjects/resources they could try to >> intercept the grant via continue... I just don't feel right locking thin= gs >> down to unique URLs that way.) >> > > If someone has the client credentials, they can impersonate the client, > and all bets are off. > > LOTS of RS servers return a resource specific URL -- my proposal is no > different. > > > > >> -steve >> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt wrote: >> >>> Hi Stephen >>> >>> The client is signing the first request. The key *might* be in the body= . >>> The client is signing all the subsequent requests as well. The "access >>> token" is not needed by the client to prove it is authorized as the cli= ent >>> is proving it is the same client again. >>> >>> In other words, I don't see the need for an access token, so it does no= t >>> need to be put in a URL or an auth header. >>> >>> If a developer really, really wants to hand context back to the client >>> for subsequent calls, they can put it in the URL or some other method. >>> Putting it in the HTTP Authorization header is confusing because it is = NOT >>> an access token -- it is the context of the request. >>> >>> =E1=90=A7 >>> >>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore wrote= : >>> >>>> Even though I've only been lightly following things, I feel the need t= o >>>> voice my preference as a developer since I will probably someday have = to >>>> either write a RC or RS... >>>> >>>> The way I see it is the RC makes the initial request to the AS as part >>>> of this request, it provides it's key in the body... (So no use of the >>>> Authorization header) >>>> At this point that request, represented by the continue URL + "Access >>>> Token", from my lazy developer standpoint, is a Resource Endpoint and >>>> Access Token, and the AS is acting as a specialized RS in this case. >>>> So my client posts to whatever URL with the 'access token' in the >>>> authorization header, just like acting on any other resource I have a = token >>>> for. YES, I get a new token value to use every call, and there is a >>>> decision point of "Do I have another continue, or do I have a real tok= en >>>> for the resource..." But the mechanism is the same to me in the client= . >>>> Personally I like that, because if I have an access_token, I already >>>> think "Put it in the auth header." >>>> >>>> So my vote would be +1 for the pull request at this time. >>>> -steve >>>> >>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>> wrote: >>>> >>>>> inline ... >>>>> >>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote= : >>>>> >>>>>> Others had already responded to this previous thread, but I wanted t= o >>>>>> add a couple points to clarify some things. >>>>>> >>>>>> 3) What the client has to do with the "access token" is not the same >>>>>> as access tokens for an RS. The client gets a new "access token" for= each >>>>>> grant request, and for each API call to the AS, and the client learn= s it >>>>>> can not make any more API calls for that specific request when it do= es not >>>>>> get an "access token" back. This is a completely different design pa= ttern >>>>>> than calling an RS API with an access token, and is a new design pat= tern >>>>>> for calling APIs. This adds complexity to the client that it would n= ot >>>>>> normally have, and I don't think GNAP is the right place to start a = new >>>>>> design pattern. >>>>>> >>>>>> >>>>>> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point >>>>>> of the design is that the client would be doing the same thing with = the >>>>>> access token at the AS that it does with the RS by re-using the acce= ss >>>>>> token structure. Can you please describe what the differences are, a= part >>>>>> from the rotation? Presentation of the token and signing of the mess= age are >>>>>> identical. >>>>>> >>>>> >>>>> The client is getting the "access token" from its API. It is not usin= g >>>>> an "access_token" in other API calls to the AS. >>>>> >>>>> >>>>>> >>>>>> Rotation of the access token and artifacts for ongoing continuation >>>>>> responses is a separate issue to be discussed: >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >>>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right place = to have >>>>>> new designs =E2=80=94 not that this is one. >>>>>> >>>>> >>>>> You are proposing a new way for an API to provide context for >>>>> subsequent API calls. Looks out of scope to me. >>>>> >>>>> >>>>>> >>>>>> 4) Clients that only want claims from the AS and no access tokens >>>>>> will be required to support an API calling mechanism they would not = have to >>>>>> support otherwise. >>>>>> >>>>>> >>>>>> Correct, but the delta between the calls a client would make with an= d >>>>>> without an access token is vanishingly small. The client has to sign= the >>>>>> initial request in some fashion, and it will sign the continuation r= equest >>>>>> in the same exact fashion, but now include an access token in that r= equest. >>>>>> >>>>> >>>>> Per my other point, there is no value to me in my implementations of >>>>> passing context back and forth between the client and AS -- so it is = extra >>>>> work providing no value. >>>>> >>>>> Also, any client authentication mechanism that wants to use the HTTP >>>>> Authentication header is precluded from using it. >>>>> >>>>> >>>>> >>>>>> >>>>>> Clients making a request to an AS and not getting an access token is >>>>>> a new design pattern. I think it has value and should be included, b= ut >>>>>> OAuth today shows us the immense value of getting access tokens for = calling >>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>> >>>>>> >>>>>> 5) If the AS does not provide an "access token", there is no >>>>>> mechanism for a client to delete the request, as the client is not a= llowed >>>>>> to make a call without an "access token". >>>>>> >>>>>> >>>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the >>>>>> client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2= =80=99s intentional. The AS is >>>>>> telling this client instance that it can=E2=80=99t do anything else = with this >>>>>> ongoing request. If the AS wants to allow the client to manage it, i= t will >>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fi= eld. >>>>>> >>>>> >>>>> There is nuance in that intention. A related concern is that deleting >>>>> a request does not seem like it is a "continue" operation. >>>>> >>>>> >>>>>> >>>>>> >>>>>> 6) There is no standard identifier for the request. Debugging and >>>>>> auditing are hampered by the client and AS having no standard way to >>>>>> identifying a request. While one AS may provide a unique URL for eac= h grant >>>>>> request, another AS may use a persistent "access token" to identify = the >>>>>> grant request, and other ASs may issue a new "access token" on each = API >>>>>> call, providing no persistent identifier for the request. >>>>>> >>>>>> >>>>>> Debugging and auditing this kind of thing are functions of the AS. >>>>>> How is interoperability harmed by different ASs having different met= hods to >>>>>> identify their internal data elements? The client doesn=E2=80=99t ne= ed any >>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the= next steps for >>>>>> continuing the negotiation. >>>>>> >>>>> >>>>> Debugging between the client and the AS was what I was referring to. >>>>> How does a client developer identify the request when communicating t= o the >>>>> AS developer. Seems complicated. >>>>> >>>>> =E1=90=A7 >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> =E1=90=A7 > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d86a5605b63aa6ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Again speaking in my own name here.=C2=A0

Dick, we know yo= u'd prefer to have a different design, but this PR shouldn't be abo= ut that.=C2=A0

Back on y= our 3 items :

1) yes we = could make pre-register mandatory, but we already decided that wouldn't= be how that would work. We have a client instance that allows a more gener= ic and flexible pattern (which BTW also allows what you want)=C2=A0

2) instead of blame arguments o= f who's less restful/HATEOAS/whatever that have the tenancy to flame co= nversations, I suggest we speak in less abstract terms and ask ourselves wh= at that means in practice for devs. Stephen and several others (myself incl= uded) have expressed that it wouldn't be harder to implement, it would = even simplify things quite a lot. If you disagree please send us a code sam= ple to really show that point by example, because that's really not obv= ious.=C2=A0

3) "If = someone has the client credentials, they can impersonate the client, and al= l bets are off." Are you seriously making this argument? Because if yo= u have a better proposal than using cryptographic keys, I'm all hears. = You make it look like there's a problem, while in reality we're onl= y relying on the basic assumption of all modern digital communications.=C2= =A0
=C2=A0
And more important= ly you never responded to the issues of how to avoid the security pitfalls = of what you proposed.=C2=A0

Fabien=C2=A0


Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Di= ck Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

<= br>
On Fri,= Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com&= gt; wrote:
But from the spec:
"
When sending a non-continuation request to the = AS, the RC MUST identify itself by including the=C2=A0client=C2=A0field of the request...
...
key (object / string) : Th= e public key of the RC to be used in this request as described in {{request= -key}}. This field is REQUIRED.=C2=A0
...
"=
So on the initial request, the key will be there= .=C2=A0

The cl= ient field can be an object or a string. If the client is pre-registered, t= hen a string could be provided instead of an object.
=C2=A0

<= /span>
If you don't have the access token, then how do you di= fferentiate between two requests from the same web application by two diffe= rent users? Is the web application supposed to have different credentials f= or every request?

The AS return= s=C2=A0a URI for manipulating the request. I would change the spec so that = each request would have a unique URI. This is the usually RESTful=C2=A0patt= ern that the resource (the grant request) has an URI.

<= div>=C2=A0
So in this case, the easy way out is to pass the access to= ken to the client, who then, as i stated before, treats the continue reques= t as a RS call (albeit=C2=A0a specialized=C2=A0version of the RS where the = RS is the AS) OR to use the unique URL,=C2=A0
but that seems open= to a brute force attack by a malicious RC. (What would be the point of tha= t attack, I don't know, I guess if someone had the client credentials b= ut not any subjects/resources they could try to intercept the grant via con= tinue... I just don't feel right locking things down to unique URLs tha= t way.)

If someone has the clie= nt credentials, they can impersonate=C2=A0the client, and all bets are off.=

LOTS of RS servers return a resource specific URL= -- my proposal is no different.


= =C2=A0
-steve

On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Stephen

Th= e client is signing the first request. The key *might* be in the body. The = client is signing all the subsequent requests as well. The "access tok= en" is not needed by the client to prove it is authorized as the clien= t is proving it is the same client again.

In other= words, I don't see the need for an access token, so it does not need t= o be put in a URL or an auth header.

If a develope= r really, really wants to hand context back to the client for subsequent ca= lls, they can put it in the URL or some other method. Putting it in the HTT= P Authorization header is confusing because it is NOT an access token -- it= is the context of the request.

3D""=E1=90= =A7

On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoo= re@gmail.com> wrote:
Even though I've only been light= ly following things, I feel the need to voice my preference as a developer = since I will probably someday have to either write a RC or RS...=C2=A0

The way I see it is the RC makes the initial request t= o the AS as part of this request, it provides it's key in the body... (= So no use of the Authorization header)
At this point that request= , represented by the continue URL=C2=A0+ "Access Token", from my = lazy developer standpoint, is a Resource Endpoint and Access Token, and the= AS is acting as a specialized RS in this case.
So my client post= s to whatever URL with the 'access token' in the authorization head= er, just like acting on any other resource I have a token for. YES, I get a= new token value to use every call, and there is a decision point of "= Do I have another continue, or do I have a real token for the resource...&q= uot; But the mechanism is the same to me in the client.
Personall= y I like that, because if I have an access_token, I already think "Put= it in the auth header."=C2=A0

So my vote wou= ld be=C2=A0+1 for the pull request at this time.
-steve

On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gm= ail.com> wrote:
inline ...=C2=A0

On Fri, Dec 11, 20= 20 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
<= /div>
Others had alre= ady responded to this previous thread, but I wanted to add a couple points = to clarify some things.

3) What the = client has to do with the "access token" is not the same as acces= s tokens for an RS. The client gets a new "access token" for each= grant request, and for each API call to the AS, and the client learns it c= an not make any more API calls for that specific request when it does not g= et an "access token" back. This is a completely different design = pattern than calling an RS API with an access token,=C2=A0and is a new desi= gn pattern for calling APIs. This adds complexity to the client that it wou= ld not normally have, and I don't think GNAP is the right place to star= t a new design pattern.


I=E2=80=99m not sure what you mean by these being different =E2=80=94 the= whole point of the design is that the client would be doing the same thing= with the access token at the AS that it does with the RS by re-using the a= ccess token structure. Can you please describe what the differences are, ap= art from the rotation? Presentation of the token and signing of the message= are identical.

The clien= t is getting the "access token" from its API. It is not using an = "access_token" in other API calls to the AS.
=C2=A0

Rotation of the access token and artifacts for ongoing continuation = responses is a separate issue to be discussed:=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/87

And for what it=E2=80=99s worth, GNAP= is absolutely the right place to have new designs =E2=80=94 not that this = is one.

You are proposing= a new way for an API to provide context for subsequent API calls. Looks ou= t of scope to me.
=C2=A0

4) Clients that= only want claims from the AS and no access tokens will be required to supp= ort an API calling mechanism they would not have to support otherwise.=C2= =A0

Correct, but the delta between th= e calls a client would make with and without an access token is vanishingly= small. The client has to sign the initial request in some fashion, and it = will sign the continuation request in the same exact fashion, but now inclu= de an access token in that request.=C2=A0

Per my other point, there is no value to me in my implemen= tations of passing context back and forth between the client and AS -- so i= t is extra work providing no value.

Also, any clie= nt authentication mechanism=C2=A0that wants to use the HTTP Authentication = header is precluded from using it.

=C2=A0

Clients making a request to an AS and not getting an access token is a ne= w design pattern. I think it has value and should be included, but OAuth to= day shows us the immense value of getting access tokens for calling APIs, a= nd so we shouldn=E2=80=99t optimize away from that pattern.


5) If the AS does not provide an &q= uot;access token", there is no mechanism for a client to delete the re= quest, as the client is not allowed to make a call without an "access = token".

More properly, if the AS= does not provide a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2= =80=99t delete the request =E2=80=94 and yes, that=E2=80=99s intentional. T= he AS is telling this client instance that it can=E2=80=99t do anything els= e with this ongoing request. If the AS wants to allow the client to manage = it, it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80= =9D field.

There is nuanc= e in that intention. A related concern is that deleting a request does not = seem like it is a "continue" operation.
=C2=A0


6) There is no standard identifier for = the request. Debugging and auditing are hampered by the client and AS havin= g no standard way to identifying a request. While one AS may provide a uniq= ue URL for each grant request, another AS may use a persistent "access= token" to identify the grant request, and other ASs may=C2=A0issue a = new "access token" on each API call, providing no persistent iden= tifier for the request.

Debugging and audi= ting this kind of thing are functions of the AS. How is interoperability ha= rmed by different ASs having different methods to identify their internal d= ata elements? The client doesn=E2=80=99t need any knowledge of the AS=E2=80= =99s identifiers, it just needs to know the next steps for continuing the n= egotiation.

Debugging between t= he client and the AS was what I was referring to. How does a client develop= er identify the request when communicating to the AS developer. Seems compl= icated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
3D""= =E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--000000000000d86a5605b63aa6ca-- From nobody Fri Dec 11 18:15:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A960C3A0D3A for ; Fri, 11 Dec 2020 18:15:27 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecNFWCCaVE_B for ; Fri, 11 Dec 2020 18:15:24 -0800 (PST) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 8AD723A0D39 for ; Fri, 11 Dec 2020 18:15:24 -0800 (PST) Received: by mail-yb1-xb2a.google.com with SMTP id r127so9841994yba.10 for ; Fri, 11 Dec 2020 18:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N6SHi2tmmGDa4SnwEQM4wuJgVNgyREhCKas72Oc0Y4g=; b=GZevHpwBwby0iMOQEAPlHeNOkFRbAvF/oXi/N8s3AD1WwO42+MT24xgON09kmrwmNL D+uca6yj3ciJXGOsv8GJEMHYsMYN4atWeDHPLkhqn62AXLxEB0iu5zDwPDV/abJ6Luj0 +qGnEQkXqmBYNe6/DTGqNHJX8HlNLUS4jS9ap91GcHIMyfOLcavmg6FMDEeY/JwK0rUC Hp4aoYIxrt92jdlHloxWfk3bHygOA+dOk1+TYo6iXYXMXTH7B6dSXuv4ee0unjJbnaYr 7CsQtQIHq8PlpmgZ4n1w/fsaM9ArRLfNCGh08btrRsmlq2YBSwLhHuIrCtKVazPwWJNL 7IKg== 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=N6SHi2tmmGDa4SnwEQM4wuJgVNgyREhCKas72Oc0Y4g=; b=ajf5cl66V9bjpngncNMRPSFmxVjm5ucHlFxonQPwMQrLVsGLByzrMR7uA31U504a7p gifo77tsh9u08HeUVLdaVwiuucbSrYDshY/zIArrPP+LaHQKXAOLLosU8dZSphtFZCSD FKhFOiOPfAAxww/4gXHZ3H8WJI9YgNAfqnm3HteWmZT/JUrAS3S0kA1TvVzeYzcsdqsE rt1ekuL60Yn7fRGjh/2AkclefV//Cg0+SEzamsWY50lWvPTVkMm9NJVWz5kB02TXG8lb X/gGSbcuRN+wg6iufWHvTSDDCNu0xLHcqT0Klm1QCKyLymz1z8s8rUMNkB/PxWxyuOU6 n1lg== X-Gm-Message-State: AOAM531kHfytj9Vmd3KsS3QccUHbVyXH7kxsgVqHP1cM7TSzpm6P+lpj qIsjRFhNG9kGYiq6LCNJARmYKQcb9QTpCJ1uTaYM50uCxCw= X-Google-Smtp-Source: ABdhPJwY+KvKY7aHN6+5kSq0vUATjiibxVcdbZA16SfnjNVr4SySprdd1UGZ2Mc6Yx3CYU7/BPKUBhSKmLhbvElbqBk= X-Received: by 2002:a25:4f0a:: with SMTP id d10mr22478291ybb.100.1607739323751; Fri, 11 Dec 2020 18:15:23 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Stephen Moore Date: Fri, 11 Dec 2020 21:15:12 -0500 Message-ID: To: Fabien Imbault Cc: Dick Hardt , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="00000000000048a27905b63afbde" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 02:15:28 -0000 --00000000000048a27905b63afbde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabien, For #3) Even after I typed out the hypothetical attack, that was sort of in the back of my mind, it isn't a huge risk there. So I actually agree with Dick there. Something doesn't sit right with me for the unique URL solution, so I don't like it and came up with a hypothetical that seems like it could be a down side. I still think the access token model with the signed request is the way I'd like to go, because again, it's a mechanism I'd be implementing anyway to talk to any 'normal' resource. The fact is there is _something_ representing context that has to pass back and forth here, whether that is an access token (which I feel like is more flexible for extensions etc), a unique url, or even a cookie sent in the cookie header. So just to re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;) -steve On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault wrote: > Again speaking in my own name here. > > Dick, we know you'd prefer to have a different design, but this PR > shouldn't be about that. > > Back on your 3 items : > > 1) yes we could make pre-register mandatory, but we already decided that > wouldn't be how that would work. We have a client instance that allows a > more generic and flexible pattern (which BTW also allows what you want) > > 2) instead of blame arguments of who's less restful/HATEOAS/whatever that > have the tenancy to flame conversations, I suggest we speak in less > abstract terms and ask ourselves what that means in practice for devs. > Stephen and several others (myself included) have expressed that it > wouldn't be harder to implement, it would even simplify things quite a lo= t. > If you disagree please send us a code sample to really show that point by > example, because that's really not obvious. > > 3) "If someone has the client credentials, they can impersonate the > client, and all bets are off." Are you seriously making this argument? > Because if you have a better proposal than using cryptographic keys, I'm > all hears. You make it look like there's a problem, while in reality we'r= e > only relying on the basic assumption of all modern digital communications= . > > And more importantly you never responded to the issues of how to avoid th= e > security pitfalls of what you proposed. > > Fabien > > > Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = a =C3=A9crit : > >> >> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore wrote: >> >>> But from the spec: >>> " >>> When sending a non-continuation request to the AS, the RC MUST identify >>> itself by including the client field of the request... >>> ... >>> key (object / string) : The public key of the RC to be used in this >>> request as described in {{request-key}}. This field is REQUIRED. >>> ... >>> " >>> >> So on the initial request, the key will be there. >>> >> >> The client field can be an object or a string. If the client is >> pre-registered, then a string could be provided instead of an object. >> >>> >> >>> >>> If you don't have the access token, then how do you differentiate >>> between two requests from the same web application by two different use= rs? >>> Is the web application supposed to have different credentials for every >>> request? >>> >> >> The AS returns a URI for manipulating the request. I would change the >> spec so that each request would have a unique URI. This is the usually >> RESTful pattern that the resource (the grant request) has an URI. >> >> >> >>> So in this case, the easy way out is to pass the access token to the >>> client, who then, as i stated before, treats the continue request as a = RS >>> call (albeit a specialized version of the RS where the RS is the AS) OR= to >>> use the unique URL, >>> but that seems open to a brute force attack by a malicious RC. (What >>> would be the point of that attack, I don't know, I guess if someone had= the >>> client credentials but not any subjects/resources they could try to >>> intercept the grant via continue... I just don't feel right locking thi= ngs >>> down to unique URLs that way.) >>> >> >> If someone has the client credentials, they can impersonate the client, >> and all bets are off. >> >> LOTS of RS servers return a resource specific URL -- my proposal is no >> different. >> >> >> >> >>> -steve >>> >>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt wrote= : >>> >>>> Hi Stephen >>>> >>>> The client is signing the first request. The key *might* be in the >>>> body. The client is signing all the subsequent requests as well. The >>>> "access token" is not needed by the client to prove it is authorized a= s the >>>> client is proving it is the same client again. >>>> >>>> In other words, I don't see the need for an access token, so it does >>>> not need to be put in a URL or an auth header. >>>> >>>> If a developer really, really wants to hand context back to the client >>>> for subsequent calls, they can put it in the URL or some other method. >>>> Putting it in the HTTP Authorization header is confusing because it is= NOT >>>> an access token -- it is the context of the request. >>>> >>>> =E1=90=A7 >>>> >>>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>> wrote: >>>> >>>>> Even though I've only been lightly following things, I feel the need >>>>> to voice my preference as a developer since I will probably someday h= ave to >>>>> either write a RC or RS... >>>>> >>>>> The way I see it is the RC makes the initial request to the AS as par= t >>>>> of this request, it provides it's key in the body... (So no use of th= e >>>>> Authorization header) >>>>> At this point that request, represented by the continue URL + "Access >>>>> Token", from my lazy developer standpoint, is a Resource Endpoint and >>>>> Access Token, and the AS is acting as a specialized RS in this case. >>>>> So my client posts to whatever URL with the 'access token' in the >>>>> authorization header, just like acting on any other resource I have a= token >>>>> for. YES, I get a new token value to use every call, and there is a >>>>> decision point of "Do I have another continue, or do I have a real to= ken >>>>> for the resource..." But the mechanism is the same to me in the clien= t. >>>>> Personally I like that, because if I have an access_token, I already >>>>> think "Put it in the auth header." >>>>> >>>>> So my vote would be +1 for the pull request at this time. >>>>> -steve >>>>> >>>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> inline ... >>>>>> >>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Others had already responded to this previous thread, but I wanted >>>>>>> to add a couple points to clarify some things. >>>>>>> >>>>>>> 3) What the client has to do with the "access token" is not the sam= e >>>>>>> as access tokens for an RS. The client gets a new "access token" fo= r each >>>>>>> grant request, and for each API call to the AS, and the client lear= ns it >>>>>>> can not make any more API calls for that specific request when it d= oes not >>>>>>> get an "access token" back. This is a completely different design p= attern >>>>>>> than calling an RS API with an access token, and is a new design pa= ttern >>>>>>> for calling APIs. This adds complexity to the client that it would = not >>>>>>> normally have, and I don't think GNAP is the right place to start a= new >>>>>>> design pattern. >>>>>>> >>>>>>> >>>>>>> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole >>>>>>> point of the design is that the client would be doing the same thin= g with >>>>>>> the access token at the AS that it does with the RS by re-using the= access >>>>>>> token structure. Can you please describe what the differences are, = apart >>>>>>> from the rotation? Presentation of the token and signing of the mes= sage are >>>>>>> identical. >>>>>>> >>>>>> >>>>>> The client is getting the "access token" from its API. It is not >>>>>> using an "access_token" in other API calls to the AS. >>>>>> >>>>>> >>>>>>> >>>>>>> Rotation of the access token and artifacts for ongoing continuation >>>>>>> responses is a separate issue to be discussed: >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>> >>>>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right place= to have >>>>>>> new designs =E2=80=94 not that this is one. >>>>>>> >>>>>> >>>>>> You are proposing a new way for an API to provide context for >>>>>> subsequent API calls. Looks out of scope to me. >>>>>> >>>>>> >>>>>>> >>>>>>> 4) Clients that only want claims from the AS and no access tokens >>>>>>> will be required to support an API calling mechanism they would not= have to >>>>>>> support otherwise. >>>>>>> >>>>>>> >>>>>>> Correct, but the delta between the calls a client would make with >>>>>>> and without an access token is vanishingly small. The client has to= sign >>>>>>> the initial request in some fashion, and it will sign the continuat= ion >>>>>>> request in the same exact fashion, but now include an access token = in that >>>>>>> request. >>>>>>> >>>>>> >>>>>> Per my other point, there is no value to me in my implementations of >>>>>> passing context back and forth between the client and AS -- so it is= extra >>>>>> work providing no value. >>>>>> >>>>>> Also, any client authentication mechanism that wants to use the HTTP >>>>>> Authentication header is precluded from using it. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Clients making a request to an AS and not getting an access token i= s >>>>>>> a new design pattern. I think it has value and should be included, = but >>>>>>> OAuth today shows us the immense value of getting access tokens for= calling >>>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>>> >>>>>>> >>>>>>> 5) If the AS does not provide an "access token", there is no >>>>>>> mechanism for a client to delete the request, as the client is not = allowed >>>>>>> to make a call without an "access token". >>>>>>> >>>>>>> >>>>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then >>>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>>>> is telling this client instance that it can=E2=80=99t do anything e= lse with this >>>>>>> ongoing request. If the AS wants to allow the client to manage it, = it will >>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D f= ield. >>>>>>> >>>>>> >>>>>> There is nuance in that intention. A related concern is that deletin= g >>>>>> a request does not seem like it is a "continue" operation. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> 6) There is no standard identifier for the request. Debugging and >>>>>>> auditing are hampered by the client and AS having no standard way t= o >>>>>>> identifying a request. While one AS may provide a unique URL for ea= ch grant >>>>>>> request, another AS may use a persistent "access token" to identify= the >>>>>>> grant request, and other ASs may issue a new "access token" on each= API >>>>>>> call, providing no persistent identifier for the request. >>>>>>> >>>>>>> >>>>>>> Debugging and auditing this kind of thing are functions of the AS. >>>>>>> How is interoperability harmed by different ASs having different me= thods to >>>>>>> identify their internal data elements? The client doesn=E2=80=99t n= eed any >>>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know th= e next steps for >>>>>>> continuing the negotiation. >>>>>>> >>>>>> >>>>>> Debugging between the client and the AS was what I was referring to. >>>>>> How does a client developer identify the request when communicating = to the >>>>>> AS developer. Seems complicated. >>>>>> >>>>>> =E1=90=A7 >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> =E1=90=A7 >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000048a27905b63afbde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabien,

For #3) Even after I typed o= ut the hypothetical attack, that was sort of in the back of my mind, it isn= 't a huge risk there. So I actually agree with Dick there. Something do= esn't sit right with me for the unique URL solution, so I don't lik= e it and came up with a hypothetical that seems like it could be a down sid= e.

I still think the access token model with the s= igned request is the way I'd like to go, because again, it's a mech= anism=C2=A0I'd be implementing=C2=A0anyway to talk to any 'normal&#= 39; resource. The fact is there is _something_ representing context that ha= s to pass back and forth here, whether that is an access token (which I fee= l like is more flexible for extensions etc), a unique url, or even a cookie= sent in the cookie header. So just to re-iterate, I'm a=C2=A0+1 on thi= s pull request, speaking as a lazy developer ;)
-steve

On Fr= i, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Again speakin= g in my own name here.=C2=A0

<= /div>
Dick, we know you'd prefer to have a different d= esign, but this PR shouldn't be about that.=C2=A0

Back on your 3 items :

1) yes we could make pre-register mandatory, b= ut we already decided that wouldn't be how that would work. We have a c= lient instance that allows a more generic and flexible pattern (which BTW a= lso allows what you want)=C2=A0

2) instead of blame arguments of who's less restful/HATEOAS/w= hatever that have the tenancy to flame conversations, I suggest we speak in= less abstract terms and ask ourselves what that means in practice for devs= . Stephen and several others (myself included) have expressed that it would= n't be harder to implement, it would even simplify things quite a lot. = If you disagree please send us a code sample to really show that point by e= xample, because that's really not obvious.=C2=A0

3) "If someone has the client credentials= , they can impersonate the client, and all bets are off." Are you seri= ously making this argument? Because if you have a better proposal than usin= g cryptographic keys, I'm all hears. You make it look like there's = a problem, while in reality we're only relying on the basic assumption = of all modern digital communications.=C2=A0
=C2=A0
And more importantly you never responded to the issue= s of how to avoid the security pitfalls of what you proposed.=C2=A0

Fabien=C2=A0


Le= sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com= > a =C3=A9crit=C2=A0:


On Fri, Dec 11, 2020 at = 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
But f= rom the spec:
"
When sending a non-continuation request to the AS, the RC MUST i= dentify itself by including the=C2=A0client=C2=A0field of the request...
...
key (object / string) : The public key of t= he RC to be used in this request as described in {{request-key}}. This fiel= d is REQUIRED.=C2=A0
...
"
So on the initial request, the key will be there.=C2=A0

The client field can be= an object or a string. If the client is pre-registered, then a string coul= d be provided instead of an object.
=C2=A0<= /div>

= If you don't have the access token, then how do you differentiate betwe= en two requests from the same web application by two different users? Is th= e web application supposed to have different credentials for every request?=

The AS returns=C2=A0a URI for = manipulating the request. I would change the spec so that each request woul= d have a unique URI. This is the usually RESTful=C2=A0pattern that the reso= urce (the grant request) has an URI.

=C2=A0
= So in this case, the easy way out is to pass the access token to the client= , who then, as i stated before, treats the continue request as a RS call (a= lbeit=C2=A0a specialized=C2=A0version of the RS where the RS is the AS) OR = to use the unique URL,=C2=A0
but that seems open to a brute force= attack by a malicious RC. (What would be the point of that attack, I don&#= 39;t know, I guess if someone had the client credentials but not any subjec= ts/resources they could try to intercept the grant via continue... I just d= on't feel right locking things down to unique URLs that way.)

If someone has the client credentials, t= hey can impersonate=C2=A0the client, and all bets are off.

LOTS of RS servers return a resource specific URL -- my proposal i= s no different.


=C2=A0
-steve

On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gm= ail.com> wrote:
Hi Stephen

The client is signing= the first request. The key *might* be in the body. The client is signing a= ll the subsequent requests as well. The "access token" is not nee= ded by the client to prove it is authorized as the client is proving it is = the same client again.

In other words, I don't= see the need for an access token, so it does not need to be put in a URL o= r an auth header.

If a developer really, really wa= nts to hand context back to the client for subsequent calls, they can put i= t in the URL or some other method. Putting it in the HTTP Authorization hea= der is confusing because it is NOT an access token -- it is the context of = the request.

3D""=E1=90=A7
On Fr= i, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
Even though I've only been lightly following th= ings, I feel the need to voice my preference as a developer since I will pr= obably someday have to either write a RC or RS...=C2=A0

The way I see it is the RC makes the initial request to the AS as par= t of this request, it provides it's key in the body... (So no use of th= e Authorization header)
At this point that request, represented b= y the continue URL=C2=A0+ "Access Token", from my lazy developer = standpoint, is a Resource Endpoint and Access Token, and the AS is acting a= s a specialized RS in this case.
So my client posts to whatever U= RL with the 'access token' in the authorization header, just like a= cting on any other resource I have a token for. YES, I get a new token valu= e to use every call, and there is a decision point of "Do I have anoth= er continue, or do I have a real token for the resource..." But the me= chanism is the same to me in the client.
Personally I like that, = because if I have an access_token, I already think "Put it in the auth= header."=C2=A0

So my vote would be=C2=A0+1 f= or the pull request at this time.
-steve

On Fri, Dec 1= 1, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com>= wrote:
inline ...=C2=A0

On Fri, Dec 11, 2020 at 9:58 AM J= ustin Richer <jricher@mit.edu> wrote:
Others had already responded t= o this previous thread, but I wanted to add a couple points to clarify some= things.

3) What the client has to d= o with the "access token" is not the same as access tokens for an= RS. The client gets a new "access token" for each grant request,= and for each API call to the AS, and the client learns it can not make any= more API calls for that specific request when it does not get an "acc= ess token" back. This is a completely different design pattern than ca= lling an RS API with an access token,=C2=A0and is a new design pattern for = calling APIs. This adds complexity to the client that it would not normally= have, and I don't think GNAP is the right place to start a new design = pattern.


I=E2=80=99m n= ot sure what you mean by these being different =E2=80=94 the whole point of= the design is that the client would be doing the same thing with the acces= s token at the AS that it does with the RS by re-using the access token str= ucture. Can you please describe what the differences are, apart from the ro= tation? Presentation of the token and signing of the message are identical.=

The client is getting th= e "access token" from its API. It is not using an "access_to= ken" in other API calls to the AS.
=C2=A0

Rotation= of the access token and artifacts for ongoing continuation responses is a = separate issue to be discussed:=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87

And for what it=E2=80=99s worth, GNAP is absolutely = the right place to have new designs =E2=80=94 not that this is one.

You are proposing a new way for = an API to provide context for subsequent API calls. Looks out of scope to m= e.
=C2=A0
=

4) Clients that only want clai= ms from the AS and no access tokens will be required to support an API call= ing mechanism they would not have to support otherwise.=C2=A0

Correct, but the delta between the calls a client = would make with and without an access token is vanishingly small. The clien= t has to sign the initial request in some fashion, and it will sign the con= tinuation request in the same exact fashion, but now include an access toke= n in that request.=C2=A0

= Per my other point, there is no value to me in my implementations of passin= g context back and forth between the client and AS -- so it is extra work p= roviding no value.

Also, any client authentication= mechanism=C2=A0that wants to use the HTTP Authentication header is preclud= ed from using it.

=C2=A0

Clients making = a request to an AS and not getting an access token is a new design pattern.= I think it has value and should be included, but OAuth today shows us the = immense value of getting access tokens for calling APIs, and so we shouldn= =E2=80=99t optimize away from that pattern.


5) If the AS does not provide an "access token= ", there is no mechanism for a client to delete the request, as the cl= ient is not allowed to make a call without an "access token".

More properly, if the AS does not provid= e a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2=80=99t delete t= he request =E2=80=94 and yes, that=E2=80=99s intentional. The AS is telling= this client instance that it can=E2=80=99t do anything else with this ongo= ing request. If the AS wants to allow the client to manage it, it will incl= ude the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field.
<= /div>

There is nuance in that intenti= on. A related concern is that deleting a request does not seem like it is a= "continue" operation.
=C2=A0

<= div>
6) There is no standard identifier for the request. Debu= gging and auditing are hampered by the client and AS having no standard way= to identifying a request. While one AS may provide a unique URL for each g= rant request, another AS may use a persistent "access token" to i= dentify the grant request, and other ASs may=C2=A0issue a new "access = token" on each API call, providing no persistent identifier for the re= quest.

Debugging and auditing this kind of= thing are functions of the AS. How is interoperability harmed by different= ASs having different methods to identify their internal data elements? The= client doesn=E2=80=99t need any knowledge of the AS=E2=80=99s identifiers,= it just needs to know the next steps for continuing the negotiation.
=

Debugging between the client and the= AS was what I was referring to. How does a client developer identify the r= equest when communicating to the AS developer. Seems complicated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/txauth
--00000000000048a27905b63afbde-- From nobody Fri Dec 11 18:35:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F243A0D6B for ; Fri, 11 Dec 2020 18:35:14 -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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2jqUqvVXD5G for ; Fri, 11 Dec 2020 18:35:11 -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 AA6C93A09BD for ; Fri, 11 Dec 2020 18:35:11 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id y5so11496898iow.5 for ; Fri, 11 Dec 2020 18:35:11 -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=uXxHJAwAmzzL2OeKsTaGqmmYsCfvU6oiHoBDvRyJriI=; b=a/NRXwHjXw4bNSBRfRgTUnekXKMqEcgQN2QXg+F6T40vlH/feSL3j5QYjHM9sa7CxN hE+x5ddzWM/4ojddo9yNxeJHYjCEYcNQaLv50HvUFCbnkYZOO52FerQcsv7hXSeglwRb RxBnH4bHIebGi2JLLDSq5rCOuvJy59St7iaNNiNZxgGd3yMD3DwHmQw5cg0hP4sqr7Nd f9EMEL/ea+wf/BfKd3A8zxOhptC0WFDFeWwNJ2HqkJykoioyMlmqg/yGdLn+MiVCCnt+ qgjyF4V3oZ+5bOZX/dlIGOkwmvgle5tnLM3peiAgaxTXIbHjc3Q2vZGKR9+9oXADTksW 8oHA== 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=uXxHJAwAmzzL2OeKsTaGqmmYsCfvU6oiHoBDvRyJriI=; b=tDpdS+QU0hW40zTHg2XWmKN4qhkdfSL/m55nmRYl7PWzBnAq5AAfJEeMn+NpVI1HG6 w1Jy4L6RJDOdIxrk2Ev9bRVQnJrc4cbO6gzPjg3t3QyqVCXAareMdrkrqJQfQYvI6egZ qIbu93pp2fi8aZB4PiglvEwOc1RADSz3fmTzrzmqn8kxvP/8C7G99rJ6nKLuHMutC3Ud IvEDux7AUEk5cDCakquQJlYzMQ+tVeehvN9Zda24V1CLaRtujdnaENhTzH6Cl7JBvD49 VoSC0Gbck3ZGc1L3Ua9WodOolIZ2jpXxUSbOHEnGIX4ykZVXeBpWwt3Iah/D+Wwp5JCU MRJQ== X-Gm-Message-State: AOAM533/cH5lts2qIzg6f96dCna7ww60pV4ynY3htuN1kT4vDycBW55a 4ALikScdMYLUI/JpBeDLTGOglNGlh+h1AQfQDFo= X-Google-Smtp-Source: ABdhPJxZ6Oxv/LQHec0Oce94w+kshIsHJtTTD//SJPs4HeBtNlBRbs1tpMSsCARPBl7Kx57AMaGDEuGdMm0J057WUm8= X-Received: by 2002:a6b:dd13:: with SMTP id f19mr18840372ioc.74.1607740510509; Fri, 11 Dec 2020 18:35:10 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Fabien Imbault Date: Sat, 12 Dec 2020 03:34:58 +0100 Message-ID: To: Stephen Moore Cc: Dick Hardt , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="000000000000051daf05b63b424a" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 02:35:14 -0000 --000000000000051daf05b63b424a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You're completely right. Allowing the dev to be lazy is a very good thing in general, because it's what we know will work :-) Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a= =C3=A9crit : > Hi Fabien, > > For #3) Even after I typed out the hypothetical attack, that was sort of > in the back of my mind, it isn't a huge risk there. So I actually agree > with Dick there. Something doesn't sit right with me for the unique URL > solution, so I don't like it and came up with a hypothetical that seems > like it could be a down side. > > I still think the access token model with the signed request is the way > I'd like to go, because again, it's a mechanism I'd be implementing anywa= y > to talk to any 'normal' resource. The fact is there is _something_ > representing context that has to pass back and forth here, whether that i= s > an access token (which I feel like is more flexible for extensions etc), = a > unique url, or even a cookie sent in the cookie header. So just to > re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;= ) > -steve > > On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault > wrote: > >> Again speaking in my own name here. >> >> Dick, we know you'd prefer to have a different design, but this PR >> shouldn't be about that. >> >> Back on your 3 items : >> >> 1) yes we could make pre-register mandatory, but we already decided that >> wouldn't be how that would work. We have a client instance that allows a >> more generic and flexible pattern (which BTW also allows what you want) >> >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever tha= t >> have the tenancy to flame conversations, I suggest we speak in less >> abstract terms and ask ourselves what that means in practice for devs. >> Stephen and several others (myself included) have expressed that it >> wouldn't be harder to implement, it would even simplify things quite a l= ot. >> If you disagree please send us a code sample to really show that point b= y >> example, because that's really not obvious. >> >> 3) "If someone has the client credentials, they can impersonate the >> client, and all bets are off." Are you seriously making this argument? >> Because if you have a better proposal than using cryptographic keys, I'm >> all hears. You make it look like there's a problem, while in reality we'= re >> only relying on the basic assumption of all modern digital communication= s. >> >> And more importantly you never responded to the issues of how to avoid >> the security pitfalls of what you proposed. >> >> Fabien >> >> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a =C3=A9crit : >> >>> >>> >>> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore wrote= : >>> >>>> But from the spec: >>>> " >>>> When sending a non-continuation request to the AS, the RC MUST identif= y >>>> itself by including the client field of the request... >>>> ... >>>> key (object / string) : The public key of the RC to be used in this >>>> request as described in {{request-key}}. This field is REQUIRED. >>>> ... >>>> " >>>> >>> So on the initial request, the key will be there. >>>> >>> >>> The client field can be an object or a string. If the client is >>> pre-registered, then a string could be provided instead of an object. >>> >>>> >>> >>>> >>>> If you don't have the access token, then how do you differentiate >>>> between two requests from the same web application by two different us= ers? >>>> Is the web application supposed to have different credentials for ever= y >>>> request? >>>> >>> >>> The AS returns a URI for manipulating the request. I would change the >>> spec so that each request would have a unique URI. This is the usually >>> RESTful pattern that the resource (the grant request) has an URI. >>> >>> >>> >>>> So in this case, the easy way out is to pass the access token to the >>>> client, who then, as i stated before, treats the continue request as a= RS >>>> call (albeit a specialized version of the RS where the RS is the AS) O= R to >>>> use the unique URL, >>>> but that seems open to a brute force attack by a malicious RC. (What >>>> would be the point of that attack, I don't know, I guess if someone ha= d the >>>> client credentials but not any subjects/resources they could try to >>>> intercept the grant via continue... I just don't feel right locking th= ings >>>> down to unique URLs that way.) >>>> >>> >>> If someone has the client credentials, they can impersonate the client, >>> and all bets are off. >>> >>> LOTS of RS servers return a resource specific URL -- my proposal is no >>> different. >>> >>> >>> >>> >>>> -steve >>>> >>>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>> wrote: >>>> >>>>> Hi Stephen >>>>> >>>>> The client is signing the first request. The key *might* be in the >>>>> body. The client is signing all the subsequent requests as well. The >>>>> "access token" is not needed by the client to prove it is authorized = as the >>>>> client is proving it is the same client again. >>>>> >>>>> In other words, I don't see the need for an access token, so it does >>>>> not need to be put in a URL or an auth header. >>>>> >>>>> If a developer really, really wants to hand context back to the clien= t >>>>> for subsequent calls, they can put it in the URL or some other method= . >>>>> Putting it in the HTTP Authorization header is confusing because it i= s NOT >>>>> an access token -- it is the context of the request. >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>> wrote: >>>>> >>>>>> Even though I've only been lightly following things, I feel the need >>>>>> to voice my preference as a developer since I will probably someday = have to >>>>>> either write a RC or RS... >>>>>> >>>>>> The way I see it is the RC makes the initial request to the AS as >>>>>> part of this request, it provides it's key in the body... (So no use= of the >>>>>> Authorization header) >>>>>> At this point that request, represented by the continue URL + "Acces= s >>>>>> Token", from my lazy developer standpoint, is a Resource Endpoint an= d >>>>>> Access Token, and the AS is acting as a specialized RS in this case. >>>>>> So my client posts to whatever URL with the 'access token' in the >>>>>> authorization header, just like acting on any other resource I have = a token >>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>> decision point of "Do I have another continue, or do I have a real t= oken >>>>>> for the resource..." But the mechanism is the same to me in the clie= nt. >>>>>> Personally I like that, because if I have an access_token, I already >>>>>> think "Put it in the auth header." >>>>>> >>>>>> So my vote would be +1 for the pull request at this time. >>>>>> -steve >>>>>> >>>>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> inline ... >>>>>>> >>>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Others had already responded to this previous thread, but I wanted >>>>>>>> to add a couple points to clarify some things. >>>>>>>> >>>>>>>> 3) What the client has to do with the "access token" is not the >>>>>>>> same as access tokens for an RS. The client gets a new "access tok= en" for >>>>>>>> each grant request, and for each API call to the AS, and the clien= t learns >>>>>>>> it can not make any more API calls for that specific request when = it does >>>>>>>> not get an "access token" back. This is a completely different des= ign >>>>>>>> pattern than calling an RS API with an access token, and is a new = design >>>>>>>> pattern for calling APIs. This adds complexity to the client that = it would >>>>>>>> not normally have, and I don't think GNAP is the right place to st= art a new >>>>>>>> design pattern. >>>>>>>> >>>>>>>> >>>>>>>> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole >>>>>>>> point of the design is that the client would be doing the same thi= ng with >>>>>>>> the access token at the AS that it does with the RS by re-using th= e access >>>>>>>> token structure. Can you please describe what the differences are,= apart >>>>>>>> from the rotation? Presentation of the token and signing of the me= ssage are >>>>>>>> identical. >>>>>>>> >>>>>>> >>>>>>> The client is getting the "access token" from its API. It is not >>>>>>> using an "access_token" in other API calls to the AS. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Rotation of the access token and artifacts for ongoing continuatio= n >>>>>>>> responses is a separate issue to be discussed: >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>>> >>>>>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have >>>>>>>> new designs =E2=80=94 not that this is one. >>>>>>>> >>>>>>> >>>>>>> You are proposing a new way for an API to provide context for >>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 4) Clients that only want claims from the AS and no access tokens >>>>>>>> will be required to support an API calling mechanism they would no= t have to >>>>>>>> support otherwise. >>>>>>>> >>>>>>>> >>>>>>>> Correct, but the delta between the calls a client would make with >>>>>>>> and without an access token is vanishingly small. The client has t= o sign >>>>>>>> the initial request in some fashion, and it will sign the continua= tion >>>>>>>> request in the same exact fashion, but now include an access token= in that >>>>>>>> request. >>>>>>>> >>>>>>> >>>>>>> Per my other point, there is no value to me in my implementations o= f >>>>>>> passing context back and forth between the client and AS -- so it i= s extra >>>>>>> work providing no value. >>>>>>> >>>>>>> Also, any client authentication mechanism that wants to use the HTT= P >>>>>>> Authentication header is precluded from using it. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Clients making a request to an AS and not getting an access token >>>>>>>> is a new design pattern. I think it has value and should be includ= ed, but >>>>>>>> OAuth today shows us the immense value of getting access tokens fo= r calling >>>>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>>>> >>>>>>>> >>>>>>>> 5) If the AS does not provide an "access token", there is no >>>>>>>> mechanism for a client to delete the request, as the client is not= allowed >>>>>>>> to make a call without an "access token". >>>>>>>> >>>>>>>> >>>>>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, tha= t=E2=80=99s intentional. The AS >>>>>>>> is telling this client instance that it can=E2=80=99t do anything = else with this >>>>>>>> ongoing request. If the AS wants to allow the client to manage it,= it will >>>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D = field. >>>>>>>> >>>>>>> >>>>>>> There is nuance in that intention. A related concern is that >>>>>>> deleting a request does not seem like it is a "continue" operation. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 6) There is no standard identifier for the request. Debugging and >>>>>>>> auditing are hampered by the client and AS having no standard way = to >>>>>>>> identifying a request. While one AS may provide a unique URL for e= ach grant >>>>>>>> request, another AS may use a persistent "access token" to identif= y the >>>>>>>> grant request, and other ASs may issue a new "access token" on eac= h API >>>>>>>> call, providing no persistent identifier for the request. >>>>>>>> >>>>>>>> >>>>>>>> Debugging and auditing this kind of thing are functions of the AS. >>>>>>>> How is interoperability harmed by different ASs having different m= ethods to >>>>>>>> identify their internal data elements? The client doesn=E2=80=99t = need any >>>>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know t= he next steps for >>>>>>>> continuing the negotiation. >>>>>>>> >>>>>>> >>>>>>> Debugging between the client and the AS was what I was referring to= . >>>>>>> How does a client developer identify the request when communicating= to the >>>>>>> AS developer. Seems complicated. >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> =E1=90=A7 >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000051daf05b63b424a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You're completely right. Allowing the dev to be = lazy is a very good thing in general, because it's what we know will wo= rk :-)=C2=A0

Le sam. 12 d=C3=A9c. 2020 =C3=A0= 03:15, Stephen Moore <srmoore@gmai= l.com> a =C3=A9crit=C2=A0:
<= div dir=3D"ltr">Hi Fabien,

For #3) Even after I typed ou= t the hypothetical attack, that was sort of in the back of my mind, it isn&= #39;t a huge risk there. So I actually agree with Dick there. Something doe= sn't sit right with me for the unique URL solution, so I don't like= it and came up with a hypothetical that seems like it could be a down side= .

I still think the access token model with the si= gned request is the way I'd like to go, because again, it's a mecha= nism=C2=A0I'd be implementing=C2=A0anyway to talk to any 'normal= 9; resource. The fact is there is _something_ representing context that has= to pass back and forth here, whether that is an access token (which I feel= like is more flexible for extensions etc), a unique url, or even a cookie = sent in the cookie header. So just to re-iterate, I'm a=C2=A0+1 on this= pull request, speaking as a lazy developer ;)
-steve
=
On Fri= , Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
=
Again speaking in my own name here.=C2=A0

Dick, we know yo= u'd prefer to have a different design, but this PR shouldn't be abo= ut that.=C2=A0

Back on y= our 3 items :

1) yes we = could make pre-register mandatory, but we already decided that wouldn't= be how that would work. We have a client instance that allows a more gener= ic and flexible pattern (which BTW also allows what you want)=C2=A0

2) instead of blame arguments o= f who's less restful/HATEOAS/whatever that have the tenancy to flame co= nversations, I suggest we speak in less abstract terms and ask ourselves wh= at that means in practice for devs. Stephen and several others (myself incl= uded) have expressed that it wouldn't be harder to implement, it would = even simplify things quite a lot. If you disagree please send us a code sam= ple to really show that point by example, because that's really not obv= ious.=C2=A0

3) "If = someone has the client credentials, they can impersonate the client, and al= l bets are off." Are you seriously making this argument? Because if yo= u have a better proposal than using cryptographic keys, I'm all hears. = You make it look like there's a problem, while in reality we're onl= y relying on the basic assumption of all modern digital communications.=C2= =A0
=C2=A0
And more important= ly you never responded to the issues of how to avoid the security pitfalls = of what you proposed.=C2=A0

Fabien=C2=A0


Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Di= ck Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:<= br>


On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
But from the spec:
= "
When se= nding a non-continuation request to the AS, the RC MUST identify itself by = including the=C2=A0client=C2=A0= field of the request...
...
key (object / string) : The public key of the RC to be used i= n this request as described in {{request-key}}. This field is REQUIRED.=C2=A0
...
"
So on th= e initial request, the key will be there.=C2=A0

The client field can be an object or a st= ring. If the client is pre-registered, then a string could be provided inst= ead of an object.
=C2=A0

If you don't h= ave the access token, then how do you differentiate between two requests fr= om the same web application by two different users? Is the web application = supposed to have different credentials for every request?

The AS returns=C2=A0a URI for manipulating the r= equest. I would change the spec so that each request would have a unique UR= I. This is the usually RESTful=C2=A0pattern that the resource (the grant re= quest) has an URI.

=C2=A0
So in this case, t= he easy way out is to pass the access token to the client, who then, as i s= tated before, treats the continue request as a RS call (albeit=C2=A0a speci= alized=C2=A0version of the RS where the RS is the AS) OR to use the unique = URL,=C2=A0
but that seems open to a brute force attack by a malic= ious RC. (What would be the point of that attack, I don't know, I guess= if someone had the client credentials but not any subjects/resources they = could try to intercept the grant via continue... I just don't feel righ= t locking things down to unique URLs that way.)

If someone has the client credentials, they can impersonat= e=C2=A0the client, and all bets are off.

LOTS of R= S servers return a resource specific URL -- my proposal is no different.


=C2=A0
-steve

On Fri, Dec 11, = 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.co= m> wrote:
Hi Stephen

The client is signing the f= irst request. The key *might* be in the body. The client is signing all the= subsequent requests as well. The "access token" is not needed by= the client to prove it is authorized as the client is proving it is the sa= me client again.

In other words, I don't see t= he need for an access token, so it does not need to be put in a URL or an a= uth header.

If a developer really, really wants to= hand context back to the client for subsequent calls, they can put it in t= he URL or some other method. Putting it in the HTTP Authorization header is= confusing because it is NOT an access token -- it is the context of the re= quest.

3D""=E1=90=A7

On Fri, Dec 11, 2= 020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
Even though I've only been lightly following t= hings, I feel the need to voice my preference as a developer since I will p= robably someday have to either write a RC or RS...=C2=A0

The way I see it is the RC makes the initial request to the AS as pa= rt of this request, it provides it's key in the body... (So no use of t= he Authorization header)
At this point that request, represented = by the continue URL=C2=A0+ "Access Token", from my lazy developer= standpoint, is a Resource Endpoint and Access Token, and the AS is acting = as a specialized RS in this case.
So my client posts to whatever = URL with the 'access token' in the authorization header, just like = acting on any other resource I have a token for. YES, I get a new token val= ue to use every call, and there is a decision point of "Do I have anot= her continue, or do I have a real token for the resource..." But the m= echanism is the same to me in the client.
Personally I like that,= because if I have an access_token, I already think "Put it in the aut= h header."=C2=A0

So my vote would be=C2=A0+1 = for the pull request at this time.
-steve

On Fri, Dec = 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail= .com> wrote:
inline ...=C2=A0

On Fri, Dec 11, 2020= at 9:58 AM Justin Richer <jricher@mit.edu> wr= ote:
Others= had already responded to this previous thread, but I wanted to add a coupl= e points to clarify some things.

3) = What the client has to do with the "access token" is not the same= as access tokens for an RS. The client gets a new "access token"= for each grant request, and for each API call to the AS, and the client le= arns it can not make any more API calls for that specific request when it d= oes not get an "access token" back. This is a completely differen= t design pattern than calling an RS API with an access token,=C2=A0and is a= new design pattern for calling APIs. This adds complexity to the client th= at it would not normally have, and I don't think GNAP is the right plac= e to start a new design pattern.


=
I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole point of the design is that the client would be doing the = same thing with the access token at the AS that it does with the RS by re-u= sing the access token structure. Can you please describe what the differenc= es are, apart from the rotation? Presentation of the token and signing of t= he message are identical.

The client is getting the "access token" from its API. It is not= using an "access_token" in other API calls to the AS.
= =C2=A0

Rotation of the access token and artifacts for ongoing con= tinuation responses is a separate issue to be discussed:=C2=A0https://github.com/ietf-wg-gnap= /gnap-core-protocol/issues/87

And for what it= =E2=80=99s worth, GNAP is absolutely the right place to have new designs = =E2=80=94 not that this is one.

You are proposing a new way for an API to provide context for subseq= uent API calls. Looks out of scope to me.
=C2=A0

4) Clients that only want claims from the AS and no access tokens = will be required to support an API calling mechanism they would not have to= support otherwise.=C2=A0

Correct, bu= t the delta between the calls a client would make with and without an acces= s token is vanishingly small. The client has to sign the initial request in= some fashion, and it will sign the continuation request in the same exact = fashion, but now include an access token in that request.=C2=A0
=

Per my other point, there is no valu= e to me in my implementations of passing context back and forth between the= client and AS -- so it is extra work providing no value.

Also, any client authentication mechanism=C2=A0that wants to use th= e HTTP Authentication header is precluded from using it.

=C2=A0
<= div>

Clients making a request to an AS and not getting a= n access token is a new design pattern. I think it has value and should be = included, but OAuth today shows us the immense value of getting access toke= ns for calling APIs, and so we shouldn=E2=80=99t optimize away from that pa= ttern.


5) If the AS = does not provide an "access token", there is no mechanism for a c= lient to delete the request, as the client is not allowed to make a call wi= thout an "access token".

Mo= re properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D field = then the client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2= =80=99s intentional. The AS is telling this client instance that it can=E2= =80=99t do anything else with this ongoing request. If the AS wants to allo= w the client to manage it, it will include the mechanisms to do so in the = =E2=80=9Ccontinue=E2=80=9D field.

There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation.
=C2=A0
<= div>


6) There is no s= tandard identifier for the request. Debugging and auditing are hampered by = the client and AS having no standard way to identifying a request. While on= e AS may provide a unique URL for each grant request, another AS may use a = persistent "access token" to identify the grant request, and othe= r ASs may=C2=A0issue a new "access token" on each API call, provi= ding no persistent identifier for the request.

<= /div>Debugging and auditing this kind of thing are functions of the AS. How= is interoperability harmed by different ASs having different methods to id= entify their internal data elements? The client doesn=E2=80=99t need any kn= owledge of the AS=E2=80=99s identifiers, it just needs to know the next ste= ps for continuing the negotiation.

<= div>Debugging between the client and the AS was what I was referring to. Ho= w does a client developer identify the request when communicating to the AS= developer. Seems complicated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth
3D""= =E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth
--000000000000051daf05b63b424a-- From nobody Sat Dec 12 02:33:31 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48473A0FEE for ; Sat, 12 Dec 2020 02:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0wGq_GE8QCS for ; Sat, 12 Dec 2020 02:33:27 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 9AA983A0FEB for ; Sat, 12 Dec 2020 02:33:26 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id q75so10808020wme.2 for ; Sat, 12 Dec 2020 02:33:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=UwmXGXX/OVG5Zf+772Iv0vjzbPwHub5Lvtjj9MavoYk=; b=PdXOR0ZlmOz2hunL0mwSvUaQZJ0ugmnUMS0MwZBa/lIOVWNE0X2bACXDXCRWfqqUSO RvgHSO+UoRQ/yXmkWZxPwLaJlB34Z04OP4Xj/y1D4Is0JcIu2xXVcXmR6CnT/x+hDQ7V SXy7dCHf+uMtX6oWTbVThk+miEBqQA0l63jHzVGBnfiwwiHv5yYmyXmWFAFB14fdTD9g aFYaSXoBbbj5k6HpCQCqS1dwH47IkM0ikPW85TB87UXF/Fmn68ByGTsRKxh6lQg1MAbD tJLWGUHriEN2JCJV5tbwNglaRnWsR9rIOopE3G8A4OKLK22BrqwmRjrBkoBGb5JGa8cs nkvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=UwmXGXX/OVG5Zf+772Iv0vjzbPwHub5Lvtjj9MavoYk=; b=id0wBEeXPlOBdgnn7LEOmbwCFj3TF8vQ2ZXGpoqrk9hhvXKBqzftuejEPV+5UDMukL KLXCOxBrC3SFtDCMKoZmhIUW1phn1wndsi5qCVBtJg71BifXusi6nESX2ac7wEwKVG62 Eh4rLEkATF/rocyTMjlwwaDWR87qV2RE3qE+vYdz90nvVWvRruS6QC+vnV8rME7Tkyon X4uMvE48rv6EEaCM8fsq0TnrwnWRNKTC6v3BReq+ARdrV6b6waJ3HFnk5NR6Yy+Hjz/C f4kcdhsLtbuWlH1kLjENpWTZxdh73gJN2PzwZSBCoGwL/Z/ApfShzjKmdbMstckkoBVa EtJA== X-Gm-Message-State: AOAM531xcekwZOxpRpTrVlDn5mkx+grRRQB/dY1d+a7zM4omtatefMN9 uZYXgtXNJk999hH/6oMlDZK2tw== X-Google-Smtp-Source: ABdhPJwJmR/q7k1cjo8jvtakjOBEdpgCNm2qV1ARjnE20XAQ4ZvAQe5c06Qd8fIvTGMt8+x36wCh7Q== X-Received: by 2002:a1c:1c1:: with SMTP id 184mr17744733wmb.112.1607769204829; Sat, 12 Dec 2020 02:33:24 -0800 (PST) Received: from ?IPv6:2003:eb:8f1b:fae3:5541:8cbe:7369:6453? (p200300eb8f1bfae355418cbe73696453.dip0.t-ipconnect.de. [2003:eb:8f1b:fae3:5541:8cbe:7369:6453]) by smtp.gmail.com with ESMTPSA id s25sm174145wrs.49.2020.12.12.02.33.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Dec 2020 02:33:23 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-D8CA3CF8-A01B-440D-9A6D-3AA2F95CA733; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 12 Dec 2020 11:33:22 +0100 Message-Id: References: Cc: Stephen Moore , txauth gnap , Justin Richer , Dick Hardt In-Reply-To: To: Fabien Imbault X-Mailer: iPad Mail (18B92) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 10:33:30 -0000 --Apple-Mail-D8CA3CF8-A01B-440D-9A6D-3AA2F95CA733 Content-Type: multipart/alternative; boundary=Apple-Mail-16B1174C-D410-49EA-8AEC-910B52C6612F Content-Transfer-Encoding: 7bit --Apple-Mail-16B1174C-D410-49EA-8AEC-910B52C6612F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I didn=E2=80=99t follow GNAP closely so bear with me if me question seems na= ive. After having skimmed through the current draft and the PR, I=E2=80=98m not s= ure whether the continuation requests accepts any access token issued to the= RC or the particular access token returned in the =E2=80=9Econtinue=E2=80=9C= element in section 3.1.. Can you please shed some light on this? kind regards, Torsten. > Am 12.12.2020 um 03:35 schrieb Fabien Imbault : >=20 > =EF=BB=BF > You're completely right. Allowing the dev to be lazy is a very good thing i= n general, because it's what we know will work :-)=20 >=20 >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore = a =C3=A9crit : >> Hi Fabien, >>=20 >> For #3) Even after I typed out the hypothetical attack, that was sort of i= n the back of my mind, it isn't a huge risk there. So I actually agree with D= ick there. Something doesn't sit right with me for the unique URL solution, s= o I don't like it and came up with a hypothetical that seems like it could b= e a down side. >>=20 >> I still think the access token model with the signed request is the way I= 'd like to go, because again, it's a mechanism I'd be implementing anyway to= talk to any 'normal' resource. The fact is there is _something_ representin= g context that has to pass back and forth here, whether that is an access to= ken (which I feel like is more flexible for extensions etc), a unique url, o= r even a cookie sent in the cookie header. So just to re-iterate, I'm a +1 o= n this pull request, speaking as a lazy developer ;) >> -steve >>=20 >>> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault wrote: >>> Again speaking in my own name here.=20 >>>=20 >>> Dick, we know you'd prefer to have a different design, but this PR shoul= dn't be about that.=20 >>>=20 >>> Back on your 3 items : >>>=20 >>> 1) yes we could make pre-register mandatory, but we already decided that= wouldn't be how that would work. We have a client instance that allows a mo= re generic and flexible pattern (which BTW also allows what you want)=20 >>>=20 >>> 2) instead of blame arguments of who's less restful/HATEOAS/whatever tha= t have the tenancy to flame conversations, I suggest we speak in less abstra= ct terms and ask ourselves what that means in practice for devs. Stephen and= several others (myself included) have expressed that it wouldn't be harder t= o implement, it would even simplify things quite a lot. If you disagree plea= se send us a code sample to really show that point by example, because that'= s really not obvious.=20 >>>=20 >>> 3) "If someone has the client credentials, they can impersonate the clie= nt, and all bets are off." Are you seriously making this argument? Because i= f you have a better proposal than using cryptographic keys, I'm all hears. Y= ou make it look like there's a problem, while in reality we're only relying o= n the basic assumption of all modern digital communications.=20 >>> =20 >>> And more importantly you never responded to the issues of how to avoid t= he security pitfalls of what you proposed.=20 >>>=20 >>> Fabien=20 >>>=20 >>>=20 >>>> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a =C3=A9crit : >>>>=20 >>>>=20 >>>>> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore wrot= e: >>>>> But from the spec: >>>>> " >>>>> When sending a non-continuation request to the AS, the RC MUST identif= y itself by including the client field of the request... >>>>> ... >>>>> key (object / string) : The public key of the RC to be used in this re= quest as described in {{request-key}}. This field is REQUIRED.=20 >>>>> ... >>>>> " >>>>> So on the initial request, the key will be there.=20 >>>>=20 >>>>=20 >>>> The client field can be an object or a string. If the client is pre-reg= istered, then a string could be provided instead of an object. >>>> =20 >>>>>=20 >>>>> If you don't have the access token, then how do you differentiate betw= een two requests from the same web application by two different users? Is th= e web application supposed to have different credentials for every request? >>>>=20 >>>> The AS returns a URI for manipulating the request. I would change the s= pec so that each request would have a unique URI. This is the usually RESTfu= l pattern that the resource (the grant request) has an URI. >>>>=20 >>>> =20 >>>>> So in this case, the easy way out is to pass the access token to the c= lient, who then, as i stated before, treats the continue request as a RS cal= l (albeit a specialized version of the RS where the RS is the AS) OR to use t= he unique URL,=20 >>>>> but that seems open to a brute force attack by a malicious RC. (What w= ould be the point of that attack, I don't know, I guess if someone had the c= lient credentials but not any subjects/resources they could try to intercept= the grant via continue... I just don't feel right locking things down to un= ique URLs that way.) >>>>=20 >>>> If someone has the client credentials, they can impersonate the client,= and all bets are off. >>>>=20 >>>> LOTS of RS servers return a resource specific URL -- my proposal is no d= ifferent. >>>>=20 >>>>=20 >>>> =20 >>>>> -steve >>>>>=20 >>>>>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt wro= te: >>>>>> Hi Stephen >>>>>>=20 >>>>>> The client is signing the first request. The key *might* be in the bo= dy. The client is signing all the subsequent requests as well. The "access t= oken" is not needed by the client to prove it is authorized as the client is= proving it is the same client again. >>>>>>=20 >>>>>> In other words, I don't see the need for an access token, so it does n= ot need to be put in a URL or an auth header. >>>>>>=20 >>>>>> If a developer really, really wants to hand context back to the clien= t for subsequent calls, they can put it in the URL or some other method. Put= ting it in the HTTP Authorization header is confusing because it is NOT an a= ccess token -- it is the context of the request. >>>>>>=20 >>>>>> =E1=90=A7 >>>>>>=20 >>>>>>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore wr= ote: >>>>>>> Even though I've only been lightly following things, I feel the need= to voice my preference as a developer since I will probably someday have to= either write a RC or RS...=20 >>>>>>>=20 >>>>>>> The way I see it is the RC makes the initial request to the AS as pa= rt of this request, it provides it's key in the body... (So no use of the Au= thorization header) >>>>>>> At this point that request, represented by the continue URL + "Acces= s Token", from my lazy developer standpoint, is a Resource Endpoint and Acce= ss Token, and the AS is acting as a specialized RS in this case. >>>>>>> So my client posts to whatever URL with the 'access token' in the au= thorization header, just like acting on any other resource I have a token fo= r. YES, I get a new token value to use every call, and there is a decision p= oint of "Do I have another continue, or do I have a real token for the resou= rce..." But the mechanism is the same to me in the client. >>>>>>> Personally I like that, because if I have an access_token, I already= think "Put it in the auth header."=20 >>>>>>>=20 >>>>>>> So my vote would be +1 for the pull request at this time. >>>>>>> -steve >>>>>>>=20 >>>>>>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt w= rote: >>>>>>>> inline ...=20 >>>>>>>>=20 >>>>>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wr= ote: >>>>>>>>> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things. >>>>>>>>>=20 >>>>>>>>>> 3) What the client has to do with the "access token" is not the s= ame as access tokens for an RS. The client gets a new "access token" for eac= h grant request, and for each API call to the AS, and the client learns it c= an not make any more API calls for that specific request when it does not ge= t an "access token" back. This is a completely different design pattern than= calling an RS API with an access token, and is a new design pattern for cal= ling APIs. This adds complexity to the client that it would not normally hav= e, and I don't think GNAP is the right place to start a new design pattern. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the same= thing with the access token at the AS that it does with the RS by re-using t= he access token structure. Can you please describe what the differences are,= apart from the rotation? Presentation of the token and signing of the messa= ge are identical. >>>>>>>>=20 >>>>>>>> The client is getting the "access token" from its API. It is not us= ing an "access_token" in other API calls to the AS. >>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/87 >>>>>>>>>=20 >>>>>>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one. >>>>>>>>=20 >>>>>>>> You are proposing a new way for an API to provide context for subse= quent API calls. Looks out of scope to me. >>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>> 4) Clients that only want claims from the AS and no access tokens= will be required to support an API calling mechanism they would not have to= support otherwise.=20 >>>>>>>>>=20 >>>>>>>>> Correct, but the delta between the calls a client would make with a= nd without an access token is vanishingly small. The client has to sign the i= nitial request in some fashion, and it will sign the continuation request in= the same exact fashion, but now include an access token in that request.=20= >>>>>>>>=20 >>>>>>>> Per my other point, there is no value to me in my implementations o= f passing context back and forth between the client and AS -- so it is extra= work providing no value. >>>>>>>>=20 >>>>>>>> Also, any client authentication mechanism that wants to use the HTT= P Authentication header is precluded from using it. >>>>>>>>=20 >>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> Clients making a request to an AS and not getting an access token i= s a new design pattern. I think it has value and should be included, but OAu= th today shows us the immense value of getting access tokens for calling API= s, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 5) If the AS does not provide an "access token", there is no mech= anism for a client to delete the request, as the client is not allowed to ma= ke a call without an "access token". >>>>>>>>>=20 >>>>>>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the client can=E2=80=99t delete the request =E2=80=94 and yes= , that=E2=80=99s intentional. The AS is telling this client instance that it= can=E2=80=99t do anything else with this ongoing request. If the AS wants t= o allow the client to manage it, it will include the mechanisms to do so in t= he =E2=80=9Ccontinue=E2=80=9D field. >>>>>>>>=20 >>>>>>>> There is nuance in that intention. A related concern is that deleti= ng a request does not seem like it is a "continue" operation. >>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 6) There is no standard identifier for the request. Debugging and= auditing are hampered by the client and AS having no standard way to identi= fying a request. While one AS may provide a unique URL for each grant reques= t, another AS may use a persistent "access token" to identify the grant requ= est, and other ASs may issue a new "access token" on each API call, providin= g no persistent identifier for the request. >>>>>>>>>=20 >>>>>>>>> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods to= identify their internal data elements? The client doesn=E2=80=99t need any k= nowledge of the AS=E2=80=99s identifiers, it just needs to know the next ste= ps for continuing the negotiation. >>>>>>>>=20 >>>>>>>> Debugging between the client and the AS was what I was referring to= . How does a client developer identify the request when communicating to the= AS developer. Seems complicated. >>>>>>>> =20 >>>>>>>> =E1=90=A7 >>>>>>>> --=20 >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>=20 >>>> =E1=90=A7 >>>> --=20 >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJYt= SpI --Apple-Mail-16B1174C-D410-49EA-8AEC-910B52C6612F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I didn=E2=80=99t follow GNAP closely so bear w= ith me if me question seems naive.

After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued t= o the RC or the particular access token returned in the =E2=80=9Econtinue=E2= =80=9C element in section 3.1..

Can you please shed some light on this?

kind regards,
Torsten.

Am 12.12.2020 um 03:35 schrieb Fabien= Imbault <fabien.imbault@gmail.com>:

=EF=BB=BF
You're c= ompletely right. Allowing the dev to be lazy is a very good thing in general= , because it's what we know will work :-) 

<= div class=3D"gmail_quote" dir=3D"auto">
Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a =C3=A9crit :
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex">
Hi Fabien,

Fo= r #3) Even after I typed out the hypothetical attack, that was sort of in th= e back of my mind, it isn't a huge risk there. So I actually agree with Dick= there. Something doesn't sit right with me for the unique URL solution, so I= don't like it and came up with a hypothetical that seems like it could be a= down side.

I still think the access token model wi= th the signed request is the way I'd like to go, because again, it's a mecha= nism I'd be implementing anyway to talk to any 'normal' resource. T= he fact is there is _something_ representing context that has to pass back a= nd forth here, whether that is an access token (which I feel like is more fl= exible for extensions etc), a unique url, or even a cookie sent in the cooki= e header. So just to re-iterate, I'm a +1 on this pull request, speakin= g as a lazy developer ;)
-steve

On Fri, Dec 11, 2020 at 8:51 P= M Fabien Imbault <fabien.imbault@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex">
Again= speaking in my own name here. 

Dick, we know you'd prefer to have a different= design, but this PR shouldn't be about that. 
<= br>
Back on your 3 items :
1) yes we could make pre-register mandatory, but we= already decided that wouldn't be how that would work. We have a client inst= ance that allows a more generic and flexible pattern (which BTW also allows w= hat you want) 

2) in= stead of blame arguments of who's less restful/HATEOAS/whatever that have th= e tenancy to flame conversations, I suggest we speak in less abstract terms a= nd ask ourselves what that means in practice for devs. Stephen and several o= thers (myself included) have expressed that it wouldn't be harder to impleme= nt, it would even simplify things quite a lot. If you disagree please send u= s a code sample to really show that point by example, because that's really n= ot obvious. 

3) "If s= omeone has the client credentials, they can impersonate the client, and all b= ets are off." Are you seriously making this argument? Because if you have a b= etter proposal than using cryptographic keys, I'm all hears. You make it loo= k like there's a problem, while in reality we're only relying on the basic a= ssumption of all modern digital communications. 
 


The AS returns a URI for manipulating the request. I would chan= ge the spec so that each request would have a unique URI. This is the usuall= y RESTful pattern that the resource (the grant request) has an URI.

 
So in this case, the easy way out is to pas= s the access token to the client, who then, as i stated before, treats the c= ontinue request as a RS call (albeit a specialized version of the R= S where the RS is the AS) OR to use the unique URL, 
but that= seems open to a brute force attack by a malicious RC. (What would be the po= int of that attack, I don't know, I guess if someone had the client credenti= als but not any subjects/resources they could try to intercept the grant via= continue... I just don't feel right locking things down to unique URLs that= way.)

If someone has the client= credentials, they can impersonate the client, and all bets are off.

LOTS of RS servers return a resource specific URL -- m= y proposal is no different.


 
-= steve

On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Stephen

The cli= ent is signing the first request. The key *might* be in the body. The client= is signing all the subsequent requests as well. The "access token" is not n= eeded by the client to prove it is authorized as the client is proving it is= the same client again.

In other words, I don't see= the need for an access token, so it does not need to be put in a URL or an a= uth header.

If a developer really, really wants to h= and context back to the client for subsequent calls, they can put it in the U= RL or some other method. Putting it in the HTTP Authorization header is conf= using because it is NOT an access token -- it is the context of the request.=

3D""=E1=90=A7
On = Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@g= mail.com> wrote:
Even though I've only been lightly followin= g things, I feel the need to voice my preference as a developer since I will= probably someday have to either write a RC or RS... 

The way I see it is the RC makes the initial request to the AS as pa= rt of this request, it provides it's key in the body... (So no use of the Au= thorization header)
At this point that request, represented by the= continue URL + "Access Token", from my lazy developer standpoint, is a= Resource Endpoint and Access Token, and the AS is acting as a specialized R= S in this case.
So my client posts to whatever URL with the 'acces= s token' in the authorization header, just like acting on any other resource= I have a token for. YES, I get a new token value to use every call, and the= re is a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the client.=
Personally I like that, because if I have an access_token, I alre= ady think "Put it in the auth header." 

So my v= ote would be +1 for the pull request at this time.
-steve

On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
inline ... 
<= br>
On Fri, D= ec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:


=
 


4) Clients that only want claims f= rom the AS and no access tokens will be required to support an API calling m= echanism they would not have to support otherwise. 
<= div>
Correct, but the delta between the calls a client would m= ake with and without an access token is vanishingly small. The client has to= sign the initial request in some fashion, and it will sign the continuation= request in the same exact fashion, but now include an access token in that r= equest. 






5= ) If the AS does not provide an "access token", there is no mechanism for a c= lient to delete the request, as the client is not allowed to make a call wit= hout an "access token".

More properly,= if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D field then the clie= nt can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99s intent= ional. The AS is telling this client instance that it can=E2=80=99t do anyth= ing else with this ongoing request. If the AS wants to allow the client to m= anage it, it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2= =80=9D field.



6) There is no standard identifier for the request. D= ebugging and auditing are hampered by the client and AS having no standard w= ay to identifying a request. While one AS may provide a unique URL for each g= rant request, another AS may use a persistent "access token" to identify the= grant request, and other ASs may issue a new "access token" on each AP= I call, providing no persistent identifier for the request.

Debugging and auditing this kind of thing are functions of t= he AS. How is interoperability harmed by different ASs having different meth= ods to identify their internal data elements? The client doesn=E2=80=99t nee= d any knowledge of the AS=E2=80=99s identifiers, it just needs to know the n= ext steps for continuing the negotiation.
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
TXAuth@ietf.or= g
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailma= n/listinfo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg= =3DAOvVaw0r39lH4qVOu0IQPJJYtSpI
= --Apple-Mail-16B1174C-D410-49EA-8AEC-910B52C6612F-- --Apple-Mail-D8CA3CF8-A01B-440D-9A6D-3AA2F95CA733 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAxMjEyMTAzMzIyWjAvBgkqhkiG9w0BCQQxIgQg URBl/wN+zUApMWgnIKcNmfwkjmaGhAQcPxyHtunlNg8wgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAaQljTeYjC52QtjD35tJcwlavq71WR5nDdceMyhNvnouIoXvlan8s 3u3jH6jw2eXq/wUaJZ+8uCvrtSX5dnSFYG/lSVeBgLuop5smQQw5e1Taun7c1QQE3bW65lPxzSWj ChdnLQzJ5oPN4ygPn4qZmKJIc3ctohwr8IR1Dj/pCXbRafXGgLylmhysHF5/ei7F1dwtQVb2Jiz4 bCLvLCtQQHtTtNXePQQ/Awb5LtHt7MLvfac+tFEZHmH4DfyBqPGit7L+Vwc/bM+50udG4trGh/9T Z1D8dRcoD4+01KTujqJ8Z2do9AE+ZOk6mUgkzKeq2ig04s5cgdrAQnXS4PYZwwAAAAAAAA== --Apple-Mail-D8CA3CF8-A01B-440D-9A6D-3AA2F95CA733-- From nobody Sat Dec 12 03:06:35 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64093A102E for ; Sat, 12 Dec 2020 03:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzWIXKclJYUn for ; Sat, 12 Dec 2020 03:06:29 -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 3B9993A102D for ; Sat, 12 Dec 2020 03:06:29 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id z136so12193920iof.3 for ; Sat, 12 Dec 2020 03:06:29 -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=EFOwEx9MRAWLhjM9Z1AENvVNNLt6BhgsOKMYsx1Lpj8=; b=MxobhhdOVh9v293uf0T/VAptoMKJa9irFe49dHxKN5NwemqrjHzlHqU+AIrysF8LGD ZI8rvxItnJgBV4UCg4YeOMfy25qqcbHXQstueyg2ms0xdUL5u3LrlrhF7ekym5P0+O9+ PelV5I7QK7UMu+euP26FAxAN70SHJcSZeY4WfVshuWxdrYFsOGKt+0jsxdSAstxRHVbm yeb17+WhQDMHTvrFEAR4tgEoHR7ZyJiIrZ2owCuT7kMnMPZVw1WxyJJGn56tTBkJc+4E 5pCraZ6WBSn8i1IERjIvS3GYgS7WDxuBZHEaMo7SE0uc1IwCAwqT3DvFTRQeRymkIjg5 SANw== 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=EFOwEx9MRAWLhjM9Z1AENvVNNLt6BhgsOKMYsx1Lpj8=; b=t3Zsw3IaQ4BKeLJlCdYiSye8QqP2VtEBOXBhd2ITyVIHvGntc/8kON7thU2EFK9Xvm +l0YUfKaMdkhsWfNl5VDUMJUWPHtkMt8wFklRkZZOKRHZ5eiko15w/tyfVgqZDUxXdWi 9TGHi64SYhHGyRbOI9rHGJ/y7i7lpo88Z+XBMH6Mqts0laQfg11Jg+uQE8/3qWnwSrqA O5AyQlPDPrwyycYYF2sEg3wAJS0WZkuL41CgXbHRzaNA/n4VGgUfX7ysj/d/mJclN5dh LiM5pdhPeXrVYNFv3SBA9AlZqXxdcETXA17nBxChcFKfnwdbuXmAfB1Q55DZyyU5AO0E GLsg== X-Gm-Message-State: AOAM533dygTN9WUyvDkpucbXVvmMVdhyI3GT/RkjnPwvO/O9YjT40reV 4WGCre0cEWAhBpobmgZI3wuWjQBzh4YSB5oMYZ0= X-Google-Smtp-Source: ABdhPJyOMazHw6rz63DpKwAXnz9fQOHquVtws/Sip641eQYmCErZBP0JBZ/o72pY7sCP+hAvisv+U3PROdRTq4hD74M= X-Received: by 2002:a6b:dd13:: with SMTP id f19mr20731732ioc.74.1607771188318; Sat, 12 Dec 2020 03:06:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sat, 12 Dec 2020 12:06:15 +0100 Message-ID: To: Torsten Lodderstedt Cc: Stephen Moore , txauth gnap , Justin Richer , Dick Hardt Content-Type: multipart/alternative; boundary="0000000000008f596e05b64266a9" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 11:06:33 -0000 --0000000000008f596e05b64266a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On the contrary your feedback is most welcome. It doesn't accept any token, it needs the particular token as described in 3.1 and which is not a bearer token (that's what the "key" : true parameter is supposed to convey). Let us know if you need more clarifications. Best Fabien Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt a =C3=A9crit : > Hi all, > > I didn=E2=80=99t follow GNAP closely so bear with me if me question seems= naive. > > After having skimmed through the current draft and the PR, I=E2=80=98m no= t sure > whether the continuation requests accepts any access token issued to the = RC > or the particular access token returned in the =E2=80=9Econtinue=E2=80=9C= element in > section 3.1.. > > Can you please shed some light on this? > > kind regards, > Torsten. > > Am 12.12.2020 um 03:35 schrieb Fabien Imbault : > > =EF=BB=BF > You're completely right. Allowing the dev to be lazy is a very good thing > in general, because it's what we know will work :-) > > Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore = a =C3=A9crit : > >> Hi Fabien, >> >> For #3) Even after I typed out the hypothetical attack, that was sort of >> in the back of my mind, it isn't a huge risk there. So I actually agree >> with Dick there. Something doesn't sit right with me for the unique URL >> solution, so I don't like it and came up with a hypothetical that seems >> like it could be a down side. >> >> I still think the access token model with the signed request is the way >> I'd like to go, because again, it's a mechanism I'd be implementing anyw= ay >> to talk to any 'normal' resource. The fact is there is _something_ >> representing context that has to pass back and forth here, whether that = is >> an access token (which I feel like is more flexible for extensions etc),= a >> unique url, or even a cookie sent in the cookie header. So just to >> re-iterate, I'm a +1 on this pull request, speaking as a lazy developer = ;) >> -steve >> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault >> wrote: >> >>> Again speaking in my own name here. >>> >>> Dick, we know you'd prefer to have a different design, but this PR >>> shouldn't be about that. >>> >>> Back on your 3 items : >>> >>> 1) yes we could make pre-register mandatory, but we already decided tha= t >>> wouldn't be how that would work. We have a client instance that allows = a >>> more generic and flexible pattern (which BTW also allows what you want) >>> >>> 2) instead of blame arguments of who's less restful/HATEOAS/whatever >>> that have the tenancy to flame conversations, I suggest we speak in les= s >>> abstract terms and ask ourselves what that means in practice for devs. >>> Stephen and several others (myself included) have expressed that it >>> wouldn't be harder to implement, it would even simplify things quite a = lot. >>> If you disagree please send us a code sample to really show that point = by >>> example, because that's really not obvious. >>> >>> 3) "If someone has the client credentials, they can impersonate the >>> client, and all bets are off." Are you seriously making this argument? >>> Because if you have a better proposal than using cryptographic keys, I'= m >>> all hears. You make it look like there's a problem, while in reality we= 're >>> only relying on the basic assumption of all modern digital communicatio= ns. >>> >>> And more importantly you never responded to the issues of how to avoid >>> the security pitfalls of what you proposed. >>> >>> Fabien >>> >>> >>> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>> =C3=A9crit : >>> >>>> >>>> >>>> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>> wrote: >>>> >>>>> But from the spec: >>>>> " >>>>> When sending a non-continuation request to the AS, the RC MUST >>>>> identify itself by including the client field of the request... >>>>> ... >>>>> key (object / string) : The public key of the RC to be used in this >>>>> request as described in {{request-key}}. This field is REQUIRED. >>>>> ... >>>>> " >>>>> >>>> So on the initial request, the key will be there. >>>>> >>>> >>>> The client field can be an object or a string. If the client is >>>> pre-registered, then a string could be provided instead of an object. >>>> >>>>> >>>> >>>>> >>>>> If you don't have the access token, then how do you differentiate >>>>> between two requests from the same web application by two different u= sers? >>>>> Is the web application supposed to have different credentials for eve= ry >>>>> request? >>>>> >>>> >>>> The AS returns a URI for manipulating the request. I would change the >>>> spec so that each request would have a unique URI. This is the usually >>>> RESTful pattern that the resource (the grant request) has an URI. >>>> >>>> >>>> >>>>> So in this case, the easy way out is to pass the access token to the >>>>> client, who then, as i stated before, treats the continue request as = a RS >>>>> call (albeit a specialized version of the RS where the RS is the AS) = OR to >>>>> use the unique URL, >>>>> but that seems open to a brute force attack by a malicious RC. (What >>>>> would be the point of that attack, I don't know, I guess if someone h= ad the >>>>> client credentials but not any subjects/resources they could try to >>>>> intercept the grant via continue... I just don't feel right locking t= hings >>>>> down to unique URLs that way.) >>>>> >>>> >>>> If someone has the client credentials, they can impersonate the client= , >>>> and all bets are off. >>>> >>>> LOTS of RS servers return a resource specific URL -- my proposal is no >>>> different. >>>> >>>> >>>> >>>> >>>>> -steve >>>>> >>>>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> Hi Stephen >>>>>> >>>>>> The client is signing the first request. The key *might* be in the >>>>>> body. The client is signing all the subsequent requests as well. The >>>>>> "access token" is not needed by the client to prove it is authorized= as the >>>>>> client is proving it is the same client again. >>>>>> >>>>>> In other words, I don't see the need for an access token, so it does >>>>>> not need to be put in a URL or an auth header. >>>>>> >>>>>> If a developer really, really wants to hand context back to the >>>>>> client for subsequent calls, they can put it in the URL or some othe= r >>>>>> method. Putting it in the HTTP Authorization header is confusing bec= ause it >>>>>> is NOT an access token -- it is the context of the request. >>>>>> >>>>>> =E1=90=A7 >>>>>> >>>>>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>>> wrote: >>>>>> >>>>>>> Even though I've only been lightly following things, I feel the nee= d >>>>>>> to voice my preference as a developer since I will probably someday= have to >>>>>>> either write a RC or RS... >>>>>>> >>>>>>> The way I see it is the RC makes the initial request to the AS as >>>>>>> part of this request, it provides it's key in the body... (So no us= e of the >>>>>>> Authorization header) >>>>>>> At this point that request, represented by the continue URL + >>>>>>> "Access Token", from my lazy developer standpoint, is a Resource En= dpoint >>>>>>> and Access Token, and the AS is acting as a specialized RS in this = case. >>>>>>> So my client posts to whatever URL with the 'access token' in the >>>>>>> authorization header, just like acting on any other resource I have= a token >>>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>>> decision point of "Do I have another continue, or do I have a real = token >>>>>>> for the resource..." But the mechanism is the same to me in the cli= ent. >>>>>>> Personally I like that, because if I have an access_token, I alread= y >>>>>>> think "Put it in the auth header." >>>>>>> >>>>>>> So my vote would be +1 for the pull request at this time. >>>>>>> -steve >>>>>>> >>>>>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>>> wrote: >>>>>>> >>>>>>>> inline ... >>>>>>>> >>>>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Others had already responded to this previous thread, but I wante= d >>>>>>>>> to add a couple points to clarify some things. >>>>>>>>> >>>>>>>>> 3) What the client has to do with the "access token" is not the >>>>>>>>> same as access tokens for an RS. The client gets a new "access to= ken" for >>>>>>>>> each grant request, and for each API call to the AS, and the clie= nt learns >>>>>>>>> it can not make any more API calls for that specific request when= it does >>>>>>>>> not get an "access token" back. This is a completely different de= sign >>>>>>>>> pattern than calling an RS API with an access token, and is a new= design >>>>>>>>> pattern for calling APIs. This adds complexity to the client that= it would >>>>>>>>> not normally have, and I don't think GNAP is the right place to s= tart a new >>>>>>>>> design pattern. >>>>>>>>> >>>>>>>>> >>>>>>>>> I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole >>>>>>>>> point of the design is that the client would be doing the same th= ing with >>>>>>>>> the access token at the AS that it does with the RS by re-using t= he access >>>>>>>>> token structure. Can you please describe what the differences are= , apart >>>>>>>>> from the rotation? Presentation of the token and signing of the m= essage are >>>>>>>>> identical. >>>>>>>>> >>>>>>>> >>>>>>>> The client is getting the "access token" from its API. It is not >>>>>>>> using an "access_token" in other API calls to the AS. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Rotation of the access token and artifacts for ongoing >>>>>>>>> continuation responses is a separate issue to be discussed: >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>>>> >>>>>>>>> >>>>>>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right pla= ce to >>>>>>>>> have new designs =E2=80=94 not that this is one. >>>>>>>>> >>>>>>>> >>>>>>>> You are proposing a new way for an API to provide context for >>>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 4) Clients that only want claims from the AS and no access tokens >>>>>>>>> will be required to support an API calling mechanism they would n= ot have to >>>>>>>>> support otherwise. >>>>>>>>> >>>>>>>>> >>>>>>>>> Correct, but the delta between the calls a client would make with >>>>>>>>> and without an access token is vanishingly small. The client has = to sign >>>>>>>>> the initial request in some fashion, and it will sign the continu= ation >>>>>>>>> request in the same exact fashion, but now include an access toke= n in that >>>>>>>>> request. >>>>>>>>> >>>>>>>> >>>>>>>> Per my other point, there is no value to me in my implementations >>>>>>>> of passing context back and forth between the client and AS -- so = it is >>>>>>>> extra work providing no value. >>>>>>>> >>>>>>>> Also, any client authentication mechanism that wants to use the >>>>>>>> HTTP Authentication header is precluded from using it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Clients making a request to an AS and not getting an access token >>>>>>>>> is a new design pattern. I think it has value and should be inclu= ded, but >>>>>>>>> OAuth today shows us the immense value of getting access tokens f= or calling >>>>>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern= . >>>>>>>>> >>>>>>>>> >>>>>>>>> 5) If the AS does not provide an "access token", there is no >>>>>>>>> mechanism for a client to delete the request, as the client is no= t allowed >>>>>>>>> to make a call without an "access token". >>>>>>>>> >>>>>>>>> >>>>>>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, th= at=E2=80=99s intentional. The AS >>>>>>>>> is telling this client instance that it can=E2=80=99t do anything= else with this >>>>>>>>> ongoing request. If the AS wants to allow the client to manage it= , it will >>>>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D= field. >>>>>>>>> >>>>>>>> >>>>>>>> There is nuance in that intention. A related concern is that >>>>>>>> deleting a request does not seem like it is a "continue" operation= . >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 6) There is no standard identifier for the request. Debugging and >>>>>>>>> auditing are hampered by the client and AS having no standard way= to >>>>>>>>> identifying a request. While one AS may provide a unique URL for = each grant >>>>>>>>> request, another AS may use a persistent "access token" to identi= fy the >>>>>>>>> grant request, and other ASs may issue a new "access token" on ea= ch API >>>>>>>>> call, providing no persistent identifier for the request. >>>>>>>>> >>>>>>>>> >>>>>>>>> Debugging and auditing this kind of thing are functions of the AS= . >>>>>>>>> How is interoperability harmed by different ASs having different = methods to >>>>>>>>> identify their internal data elements? The client doesn=E2=80=99t= need any >>>>>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know = the next steps for >>>>>>>>> continuing the negotiation. >>>>>>>>> >>>>>>>> >>>>>>>> Debugging between the client and the AS was what I was referring >>>>>>>> to. How does a client developer identify the request when communic= ating to >>>>>>>> the AS developer. Seems complicated. >>>>>>>> >>>>>>>> =E1=90=A7 >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>>> >>>>>>> =E1=90=A7 >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>> -- > TXAuth mailing list > TXAuth@ietf.org > > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txau= th&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJ= YtSpI > > --0000000000008f596e05b64266a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On = the contrary your feedback is most welcome.=C2=A0
It doesn't accept any token, it needs the par= ticular token as described in 3.1 and which is not a bearer token (that'= ;s what the "key" : true parameter is supposed to convey).=C2=A0<= /div>

Let us know if you need = more clarifications.=C2=A0

Best
Fabien=C2=A0

Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33,= Torsten Lodderstedt <torsten= @lodderstedt.net> a =C3=A9crit=C2=A0:
Hi all,
=
I didn=E2=80=99t follow GNAP closely so bear wit= h me if me question seems naive.

After having skimmed through the current draft and the PR, I=E2=80= =98m not sure whether the continuation requests accepts any access token is= sued to the RC or the particular access token returned in the =E2=80=9Econt= inue=E2=80=9C element in section 3.1..

Can you please shed some light on this?
=
kind regards,
Torsten.

Am 12.12.2020 um 03:35 sch= rieb Fabien Imbault <fabien.imbault@gmail.com>:

=EF=BB=BF
You're completely right. Allowing the dev to be lazy is= a very good thing in general, because it's what we know will work :-)= =C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15= , Stephen Moore <srmoore@gmail.com> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi Fabien,

For #3) Even after I typed out the hypothetical attack, that was sort of = in the back of my mind, it isn't a huge risk there. So I actually agree= with Dick there. Something doesn't sit right with me for the unique UR= L solution, so I don't like it and came up with a hypothetical that see= ms like it could be a down side.

I still think the= access token model with the signed request is the way I'd like to go, = because again, it's a mechanism=C2=A0I'd be implementing=C2=A0anywa= y to talk to any 'normal' resource. The fact is there is _something= _ representing context that has to pass back and forth here, whether that i= s an access token (which I feel like is more flexible for extensions etc), = a unique url, or even a cookie sent in the cookie header. So just to re-ite= rate, I'm a=C2=A0+1 on this pull request, speaking as a lazy developer = ;)
-steve

On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <= ;fabien.imbault@gmail.com> wrote:
Again spea= king in my own name here.=C2=A0
Dick, we know you'd prefer to have a differen= t design, but this PR shouldn't be about that.=C2=A0

Back on your 3 items :

1) yes we could make pre-register mandatory= , but we already decided that wouldn't be how that would work. We have = a client instance that allows a more generic and flexible pattern (which BT= W also allows what you want)=C2=A0

2) instead of blame arguments of who's less restful/HATEOAS/= whatever that have the tenancy to flame conversations, I suggest we speak i= n less abstract terms and ask ourselves what that means in practice for dev= s. Stephen and several others (myself included) have expressed that it woul= dn't be harder to implement, it would even simplify things quite a lot.= If you disagree please send us a code sample to really show that point by = example, because that's really not obvious.=C2=A0

3) "If someone has the client credential= s, they can impersonate the client, and all bets are off." Are you ser= iously making this argument? Because if you have a better proposal than usi= ng cryptographic keys, I'm all hears. You make it look like there's= a problem, while in reality we're only relying on the basic assumption= of all modern digital communications.=C2=A0
=C2=A0<= /div>
And more importantly you never responded to the issu= es of how to avoid the security pitfalls of what you proposed.=C2=A0
<= div dir=3D"auto">
Fabien=C2=A0


L= e sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:

<= /div>
O= n Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
But from the spec:
"
=
When sending a non-= continuation request to the AS, the RC MUST identify itself by including th= e=C2=A0client<= /code>=C2=A0field of the= request...
...
So on the initial re= quest, the key will be there.=C2=A0

The client field can be an object or a string. If the= client is pre-registered, then a string could be provided instead of an ob= ject.
=C2=A0

If you don't have the acce= ss token, then how do you differentiate between two requests from the same = web application by two different users? Is the web application supposed to = have different credentials for every request?
=
The AS returns=C2=A0a URI for manipulating the request. I wo= uld change the spec so that each request would have a unique URI. This is t= he usually RESTful=C2=A0pattern that the resource (the grant request) has a= n URI.

=C2=A0
So in this case, the easy way = out is to pass the access token to the client, who then, as i stated before= , treats the continue request as a RS call (albeit=C2=A0a specialized=C2=A0= version of the RS where the RS is the AS) OR to use the unique URL,=C2=A0
but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)

=
If someone has the client credentials, they can impersonate=C2=A0the c= lient, and all bets are off.

LOTS of RS servers re= turn a resource specific URL -- my proposal is no different.

=

=C2=A0
-steve

On Fri, Dec 11, 2020 at 5:33= PM Dick Hardt <dick.hardt@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">Hi Stephen

The client is signing the fir= st request. The key *might* be in the body. The client is signing all the s= ubsequent requests as well. The "access token" is not needed by t= he client to prove it is authorized as the client is proving it is the same= client again.

In other words, I don't see the= need for an access token, so it does not need to be put in a URL or an aut= h header.

If a developer really, really wants to h= and context back to the client for subsequent calls, they can put it in the= URL or some other method. Putting it in the HTTP Authorization header is c= onfusing because it is NOT an access token -- it is the context of the requ= est.


On Fri, Dec 11, 202= 0 at 2:01 PM Stephen Moore <srmoore@gmai= l.com> wrote:
Even though I've only been lightly foll= owing things, I feel the need to voice my preference as a developer since I= will probably someday have to either write a RC or RS...=C2=A0
<= br>
The way I see it is the RC makes the initial request to the A= S as part of this request, it provides it's key in the body... (So no u= se of the Authorization header)
At this point that request, repre= sented by the continue URL=C2=A0+ "Access Token", from my lazy de= veloper standpoint, is a Resource Endpoint and Access Token, and the AS is = acting as a specialized RS in this case.
So my client posts to wh= atever URL with the 'access token' in the authorization header, jus= t like acting on any other resource I have a token for. YES, I get a new to= ken value to use every call, and there is a decision point of "Do I ha= ve another continue, or do I have a real token for the resource..." Bu= t the mechanism is the same to me in the client.
Personally I lik= e that, because if I have an access_token, I already think "Put it in = the auth header."=C2=A0

So my vote would be= =C2=A0+1 for the pull request at this time.
-steve

On = Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
inline ...=C2=A0<= /div>
O= n Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
Others had already responded to this previous threa= d, but I wanted to add a couple points to clarify some things.

3) What the client has to do with the "acce= ss token" is not the same as access tokens for an RS. The client gets = a new "access token" for each grant request, and for each API cal= l to the AS, and the client learns it can not make any more API calls for t= hat specific request when it does not get an "access token" back.= This is a completely different design pattern than calling an RS API with = an access token,=C2=A0and is a new design pattern for calling APIs. This ad= ds complexity to the client that it would not normally have, and I don'= t think GNAP is the right place to start a new design pattern.

I=E2=80=99m not sure what you mean= by these being different =E2=80=94 the whole point of the design is that t= he client would be doing the same thing with the access token at the AS tha= t it does with the RS by re-using the access token structure. Can you pleas= e describe what the differences are, apart from the rotation? Presentation = of the token and signing of the message are identical.

The client is getting the "access token&= quot; from its API. It is not using an "access_token" in other AP= I calls to the AS.
=C2=A0

Rotation of the access token = and artifacts for ongoing continuation responses is a separate issue to be = discussed:=C2=A0https://github.com/i= etf-wg-gnap/gnap-core-protocol/issues/87

And f= or what it=E2=80=99s worth, GNAP is absolutely the right place to have new = designs =E2=80=94 not that this is one.
=
You are proposing a new way for an API to provide context fo= r subsequent API calls. Looks out of scope to me.
=C2=A0

4) Clients that only want claims from the AS and no access= tokens will be required to support an API calling mechanism they would not= have to support otherwise.=C2=A0

Cor= rect, but the delta between the calls a client would make with and without = an access token is vanishingly small. The client has to sign the initial re= quest in some fashion, and it will sign the continuation request in the sam= e exact fashion, but now include an access token in that request.=C2=A0

Per my other point, there is= no value to me in my implementations of passing context back and forth bet= ween the client and AS -- so it is extra work providing no value.

Also, any client authentication mechanism=C2=A0that wants t= o use the HTTP Authentication header is precluded from using it.
=
=C2=A0

5) If= the AS does not provide an "access token", there is no mechanism= for a client to delete the request, as the client is not allowed to make a= call without an "access token".

More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the client can=E2=80=99t delete the request =E2=80=94 and ye= s, that=E2=80=99s intentional. The AS is telling this client instance that = it can=E2=80=99t do anything else with this ongoing request. If the AS want= s to allow the client to manage it, it will include the mechanisms to do so= in the =E2=80=9Ccontinue=E2=80=9D field.

There is nuance in that intention. A related concern is th= at deleting a request does not seem like it is a "continue" opera= tion.
=C2=A0


6) There= is no standard identifier for the request. Debugging and auditing are hamp= ered by the client and AS having no standard way to identifying a request. = While one AS may provide a unique URL for each grant request, another AS ma= y use a persistent "access token" to identify the grant request, = and other ASs may=C2=A0issue a new "access token" on each API cal= l, providing no persistent identifier for the request.

Debugging and auditing this kind of thing are functions of the= AS. How is interoperability harmed by different ASs having different metho= ds to identify their internal data elements? The client doesn=E2=80=99t nee= d any knowledge of the AS=E2=80=99s identifiers, it just needs to know the = next steps for continuing the negotiation.
Debugging between the client and the AS was what I was referrin= g to. How does a client developer identify the request when communicating t= o the AS developer. Seems complicated.
=C2=A0
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth
3D""= =E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txa= uth
--
TXAuth mailing list
TXAuth@ietf.org<= /a>
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listi= nfo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOv= Vaw0r39lH4qVOu0IQPJJYtSpI
--0000000000008f596e05b64266a9-- From nobody Sat Dec 12 03:43:24 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE84F3A1060 for ; Sat, 12 Dec 2020 03:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 25Ty1aDCUTSX for ; Sat, 12 Dec 2020 03:43:19 -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 9B38F3A105E for ; Sat, 12 Dec 2020 03:43:18 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BCBh8om003737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Dec 2020 06:43:16 -0500 From: Justin Richer Message-Id: <30F386EB-632E-4FBB-9561-D41B0DC6E303@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_3C191AA5-CEB6-4A20-8341-F46F359AC7E8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 12 Dec 2020 06:43:08 -0500 In-Reply-To: Cc: txauth gnap To: Torsten Lodderstedt References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2020 11:43:23 -0000 --Apple-Mail=_3C191AA5-CEB6-4A20-8341-F46F359AC7E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It=E2=80=99s the token returned in the =E2=80=9Ccontinue=E2=80=9D = request. It=E2=80=99s required to be a bound token, and specifically = bound to the client=E2=80=99s original presentation method and key (so = bearer tokens aren=E2=80=99t allowed here). This is currently specified to be a token that isn=E2=80=99t usable = elsewhere, but there=E2=80=99s a separate issue filed for whether = that=E2=80=99s a requirement (and honestly whether it=E2=80=99s = enforceable): = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66 = =E2=80=94 Justin > On Dec 12, 2020, at 5:33 AM, Torsten Lodderstedt = wrote: >=20 > Hi all, >=20 > I didn=E2=80=99t follow GNAP closely so bear with me if me question = seems naive. >=20 > After having skimmed through the current draft and the PR, I=E2=80=98m = not sure whether the continuation requests accepts any access token = issued to the RC or the particular access token returned in the = =E2=80=9Econtinue=E2=80=9C element in section 3.1.. >=20 > Can you please shed some light on this? >=20 > kind regards, > Torsten. >=20 >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault = : >>=20 >> =EF=BB=BF >> You're completely right. Allowing the dev to be lazy is a very good = thing in general, because it's what we know will work :-)=20 >>=20 >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore = > a =C3=A9crit : >> Hi Fabien, >>=20 >> For #3) Even after I typed out the hypothetical attack, that was sort = of in the back of my mind, it isn't a huge risk there. So I actually = agree with Dick there. Something doesn't sit right with me for the = unique URL solution, so I don't like it and came up with a hypothetical = that seems like it could be a down side. >>=20 >> I still think the access token model with the signed request is the = way I'd like to go, because again, it's a mechanism I'd be implementing = anyway to talk to any 'normal' resource. The fact is there is = _something_ representing context that has to pass back and forth here, = whether that is an access token (which I feel like is more flexible for = extensions etc), a unique url, or even a cookie sent in the cookie = header. So just to re-iterate, I'm a +1 on this pull request, speaking = as a lazy developer ;) >> -steve >>=20 >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault = > wrote: >> Again speaking in my own name here.=20 >>=20 >> Dick, we know you'd prefer to have a different design, but this PR = shouldn't be about that.=20 >>=20 >> Back on your 3 items : >>=20 >> 1) yes we could make pre-register mandatory, but we already decided = that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what = you want)=20 >>=20 >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever = that have the tenancy to flame conversations, I suggest we speak in less = abstract terms and ask ourselves what that means in practice for devs. = Stephen and several others (myself included) have expressed that it = wouldn't be harder to implement, it would even simplify things quite a = lot. If you disagree please send us a code sample to really show that = point by example, because that's really not obvious.=20 >>=20 >> 3) "If someone has the client credentials, they can impersonate the = client, and all bets are off." Are you seriously making this argument? = Because if you have a better proposal than using cryptographic keys, I'm = all hears. You make it look like there's a problem, while in reality = we're only relying on the basic assumption of all modern digital = communications.=20 >> =20 >> And more importantly you never responded to the issues of how to = avoid the security pitfalls of what you proposed.=20 >>=20 >> Fabien=20 >>=20 >>=20 >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = > a =C3=A9crit : >>=20 >>=20 >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore > wrote: >> But from the spec: >> " >> When sending a non-continuation request to the AS, the RC MUST = identify itself by including the client field of the request... >> ... >> key (object / string) : The public key of the RC to be used in this = request as described in {{request-key}}. This field is REQUIRED.=20 >> ... >> " >> So on the initial request, the key will be there.=20 >>=20 >> The client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object. >> =20 >>=20 >> If you don't have the access token, then how do you differentiate = between two requests from the same web application by two different = users? Is the web application supposed to have different credentials for = every request? >>=20 >> The AS returns a URI for manipulating the request. I would change the = spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI. >>=20 >> =20 >> So in this case, the easy way out is to pass the access token to the = client, who then, as i stated before, treats the continue request as a = RS call (albeit a specialized version of the RS where the RS is the AS) = OR to use the unique URL,=20 >> but that seems open to a brute force attack by a malicious RC. (What = would be the point of that attack, I don't know, I guess if someone had = the client credentials but not any subjects/resources they could try to = intercept the grant via continue... I just don't feel right locking = things down to unique URLs that way.) >>=20 >> If someone has the client credentials, they can impersonate the = client, and all bets are off. >>=20 >> LOTS of RS servers return a resource specific URL -- my proposal is = no different. >>=20 >>=20 >> =20 >> -steve >>=20 >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt > wrote: >> Hi Stephen >>=20 >> The client is signing the first request. The key *might* be in the = body. The client is signing all the subsequent requests as well. The = "access token" is not needed by the client to prove it is authorized as = the client is proving it is the same client again. >>=20 >> In other words, I don't see the need for an access token, so it does = not need to be put in a URL or an auth header. >>=20 >> If a developer really, really wants to hand context back to the = client for subsequent calls, they can put it in the URL or some other = method. Putting it in the HTTP Authorization header is confusing because = it is NOT an access token -- it is the context of the request. >>=20 >> =E1=90=A7 >>=20 >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore > wrote: >> Even though I've only been lightly following things, I feel the need = to voice my preference as a developer since I will probably someday have = to either write a RC or RS...=20 >>=20 >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of = the Authorization header) >> At this point that request, represented by the continue URL + "Access = Token", from my lazy developer standpoint, is a Resource Endpoint and = Access Token, and the AS is acting as a specialized RS in this case. >> So my client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a = token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client. >> Personally I like that, because if I have an access_token, I already = think "Put it in the auth header."=20 >>=20 >> So my vote would be +1 for the pull request at this time. >> -steve >>=20 >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt > wrote: >> inline ...=20 >>=20 >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer > wrote: >> Others had already responded to this previous thread, but I wanted to = add a couple points to clarify some things. >>=20 >>> 3) What the client has to do with the "access token" is not the same = as access tokens for an RS. The client gets a new "access token" for = each grant request, and for each API call to the AS, and the client = learns it can not make any more API calls for that specific request when = it does not get an "access token" back. This is a completely different = design pattern than calling an RS API with an access token, and is a new = design pattern for calling APIs. This adds complexity to the client that = it would not normally have, and I don't think GNAP is the right place to = start a new design pattern. >>>=20 >>=20 >> I=E2=80=99m not sure what you mean by these being different =E2=80=94 = the whole point of the design is that the client would be doing the same = thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical. >>=20 >> The client is getting the "access token" from its API. It is not = using an "access_token" in other API calls to the AS. >> =20 >>=20 >> Rotation of the access token and artifacts for ongoing continuation = responses is a separate issue to be discussed: = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = >>=20 >> And for what it=E2=80=99s worth, GNAP is absolutely the right place = to have new designs =E2=80=94 not that this is one. >>=20 >> You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me. >> =20 >>=20 >>> 4) Clients that only want claims from the AS and no access tokens = will be required to support an API calling mechanism they would not have = to support otherwise.=20 >>=20 >> Correct, but the delta between the calls a client would make with and = without an access token is vanishingly small. The client has to sign the = initial request in some fashion, and it will sign the continuation = request in the same exact fashion, but now include an access token in = that request.=20 >>=20 >> Per my other point, there is no value to me in my implementations of = passing context back and forth between the client and AS -- so it is = extra work providing no value. >>=20 >> Also, any client authentication mechanism that wants to use the HTTP = Authentication header is precluded from using it. >>=20 >> =20 >>=20 >> Clients making a request to an AS and not getting an access token is = a new design pattern. I think it has value and should be included, but = OAuth today shows us the immense value of getting access tokens for = calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern. >>=20 >>>=20 >>> 5) If the AS does not provide an "access token", there is no = mechanism for a client to delete the request, as the client is not = allowed to make a call without an "access token". >>=20 >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D = field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. >>=20 >> There is nuance in that intention. A related concern is that deleting = a request does not seem like it is a "continue" operation. >> =20 >>=20 >>>=20 >>> 6) There is no standard identifier for the request. Debugging and = auditing are hampered by the client and AS having no standard way to = identifying a request. While one AS may provide a unique URL for each = grant request, another AS may use a persistent "access token" to = identify the grant request, and other ASs may issue a new "access token" = on each API call, providing no persistent identifier for the request. >>=20 >> Debugging and auditing this kind of thing are functions of the AS. = How is interoperability harmed by different ASs having different methods = to identify their internal data elements? The client doesn=E2=80=99t = need any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps for continuing the negotiation. >>=20 >> Debugging between the client and the AS was what I was referring to. = How does a client developer identify the request when communicating to = the AS developer. Seems complicated. >> =20 >> =E1=90=A7 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> =E1=90=A7 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJ= YtSpI --Apple-Mail=_3C191AA5-CEB6-4A20-8341-F46F359AC7E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It=E2=80=99s the token returned in the =E2=80=9Ccontinue=E2=80=9D= request. It=E2=80=99s required to be a bound token, and specifically = bound to the client=E2=80=99s original presentation method and key (so = bearer tokens aren=E2=80=99t allowed here).

This is currently specified to be a = token that isn=E2=80=99t usable elsewhere, but there=E2=80=99s a = separate issue filed for whether that=E2=80=99s a requirement (and = honestly whether it=E2=80=99s enforceable): https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66

 =E2=80=94 Justin

On Dec = 12, 2020, at 5:33 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi = all,

I didn=E2=80=99t follow GNAP closely so bear with = me if me question seems naive.

After having skimmed = through the current draft and the PR, I=E2=80=98m not sure whether the = continuation requests accepts any access token issued to the RC or the = particular access token returned in the =E2=80=9Econtinue=E2=80=9C = element in section 3.1..

Can you please shed some = light on this?

kind regards,
Torsten.

Am 12.12.2020 um 03:35 = schrieb Fabien Imbault <fabien.imbault@gmail.com>:

=EF=BB=BF
You're completely right. Allowing the dev to be lazy is a = very good thing in general, because it's what we know will work = :-) 

Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen = Moore <srmoore@gmail.com> a =C3=A9crit :
Hi Fabien,

For #3) Even after I typed out the hypothetical attack, that = was sort of in the back of my mind, it isn't a huge risk there. So I = actually agree with Dick there. Something doesn't sit right with me for = the unique URL solution, so I don't like it and came up with a = hypothetical that seems like it could be a down side.

I still think the access = token model with the signed request is the way I'd like to go, because = again, it's a mechanism I'd be implementing anyway to talk to = any 'normal' resource. The fact is there is _something_ representing = context that has to pass back and forth here, whether that is an access = token (which I feel like is more flexible for extensions etc), a unique = url, or even a cookie sent in the cookie header. So just to re-iterate, = I'm a +1 on this pull request, speaking as a lazy developer = ;)
-steve

On Fri, Dec = 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Again speaking in my own name here. 

Dick, we know you'd prefer = to have a different design, but this PR shouldn't be about = that. 

Back on your 3 items :

1) yes we = could make pre-register mandatory, but we already decided that wouldn't = be how that would work. We have a client instance that allows a more = generic and flexible pattern (which BTW also allows what you = want) 

2) instead of blame arguments of who's less = restful/HATEOAS/whatever that have the tenancy to flame conversations, I = suggest we speak in less abstract terms and ask ourselves what that = means in practice for devs. Stephen and several others (myself included) = have expressed that it wouldn't be harder to implement, it would even = simplify things quite a lot. If you disagree please send us a code = sample to really show that point by example, because that's really not = obvious. 

3) "If someone has the client credentials, they = can impersonate the client, and all bets are off." Are you seriously = making this argument? Because if you have a better proposal than using = cryptographic keys, I'm all hears. You make it look like there's a = problem, while in reality we're only relying on the basic assumption of = all modern digital communications. 
 
And more importantly = you never responded to the issues of how to avoid the security pitfalls = of what you proposed. 

Fabien 


Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, = Dick Hardt <dick.hardt@gmail.com> a = =C3=A9crit :


On Fri, Dec = 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
But from = the spec:
"
When = sending a non-continuation request to the AS, the RC MUST identify = itself by including the client field of the request...
...
key = (object / string) : The public key of the RC to be used in this request = as described in {{request-key}}. This field is = REQUIRED. 
...
"
So on the initial request, the key will be = there. 

The client field can be = an object or a string. If the client is pre-registered, then a string = could be provided instead of an object.
 

If you don't have the access = token, then how do you differentiate between two requests from the same = web application by two different users? Is the web application supposed = to have different credentials for every = request?

The AS returns a URI for manipulating the request. I = would change the spec so that each request would have a unique URI. This = is the usually RESTful pattern that the resource (the grant = request) has an URI.

 
So in this case, the easy way out is to pass the access token = to the client, who then, as i stated before, treats the continue request = as a RS call (albeit a specialized version of the RS where the = RS is the AS) OR to use the unique URL, 
but = that seems open to a brute force attack by a malicious RC. (What would = be the point of that attack, I don't know, I guess if someone had the = client credentials but not any subjects/resources they could try to = intercept the grant via continue... I just don't feel right locking = things down to unique URLs that way.)

If someone has the = client credentials, they can impersonate the client, and all bets = are off.

LOTS = of RS servers return a resource specific URL -- my proposal is no = different.


 
-steve

On Fri, Dec = 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi = Stephen

The client = is signing the first request. The key *might* be in the body. The client = is signing all the subsequent requests as well. The "access token" is = not needed by the client to prove it is authorized as the client is = proving it is the same client again.

In other words, I don't see the need = for an access token, so it does not need to be put in a URL or an auth = header.

If a = developer really, really wants to hand context back to the client for = subsequent calls, they can put it in the URL or some other method. = Putting it in the HTTP Authorization header is confusing because it is = NOT an access token -- it is the context of the request.

3D""=E1=90=A7

On Fri, Dec = 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
Even though I've only been lightly following = things, I feel the need to voice my preference as a developer since I = will probably someday have to either write a RC or RS... 

The way I see it is the = RC makes the initial request to the AS as part of this request, it = provides it's key in the body... (So no use of the Authorization = header)
At this point that request, represented by = the continue URL + "Access Token", from my lazy developer = standpoint, is a Resource Endpoint and Access Token, and the AS is = acting as a specialized RS in this case.
So my = client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a = token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client.
Personally I like that, because if I have = an access_token, I already think "Put it in the auth = header." 

So my vote would be +1 for the pull request at this = time.
-steve

On Fri, Dec = 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
inline ... 

On Fri, Dec = 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
Others had = already responded to this previous thread, but I wanted to add a couple = points to clarify some things.

3) What the client has to do = with the "access token" is not the same as access tokens for an RS. The = client gets a new "access token" for each grant request, and for each = API call to the AS, and the client learns it can not make any more API = calls for that specific request when it does not get an "access token" = back. This is a completely different design pattern than calling an RS = API with an access token, and is a new design pattern for calling = APIs. This adds complexity to the client that it would not normally = have, and I don't think GNAP is the right place to start a new design = pattern.


I=E2=80=99m not sure = what you mean by these being different =E2=80=94 the whole point of the = design is that the client would be doing the same thing with the access = token at the AS that it does with the RS by re-using the access token = structure. Can you please describe what the differences are, apart from = the rotation? Presentation of the token and signing of the message are = identical.

The client is getting the "access = token" from its API. It is not using an "access_token" in other API = calls to the AS.
 

Rotation = of the access token and artifacts for ongoing continuation responses is = a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87

And for what = it=E2=80=99s worth, GNAP is absolutely the right place to have new = designs =E2=80=94 not that this is = one.

You are proposing a new way for an API = to provide context for subsequent API calls. Looks out of scope to = me.
 

4) = Clients that only want claims from the AS and no access tokens will be = required to support an API calling mechanism they would not have to = support otherwise. 

Correct, but the delta between the = calls a client would make with and without an access token is = vanishingly small. The client has to sign the initial request in some = fashion, and it will sign the continuation request in the same exact = fashion, but now include an access token in that = request. 

Per my other point, there is no value = to me in my implementations of passing context back and forth between = the client and AS -- so it is extra work providing no value.

Also, any client = authentication mechanism that wants to use the HTTP Authentication = header is precluded from using it.

 

Clients = making a request to an AS and not getting an access token is a new = design pattern. I think it has value and should be included, but OAuth = today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that = pattern.


5) If the AS does not = provide an "access token", there is no mechanism for a client to delete = the request, as the client is not allowed to make a call without an = "access token".

More properly, if the AS does not = provide a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2=80=99t = delete the request =E2=80=94 and yes, that=E2=80=99s intentional. The AS = is telling this client instance that it can=E2=80=99t do anything else = with this ongoing request. If the AS wants to allow the client to manage = it, it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80= =9D field.

There is nuance in that intention. A = related concern is that deleting a request does not seem like it is a = "continue" operation.
 


6) There is no standard identifier for = the request. Debugging and auditing are hampered by the client and AS = having no standard way to identifying a request. While one AS may = provide a unique URL for each grant request, another AS may use a = persistent "access token" to identify the grant request, and other ASs = may issue a new "access token" on each API call, providing no = persistent identifier for the request.

Debugging and auditing this kind of = thing are functions of the AS. How is interoperability harmed by = different ASs having different methods to identify their internal data = elements? The client doesn=E2=80=99t need any knowledge of the AS=E2=80=99= s identifiers, it just needs to know the next steps for continuing the = negotiation.

Debugging between the client and the AS = was what I was referring to. How does a client developer identify the = request when communicating to the AS developer. Seems = complicated.
 
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
3D""=E1=90=A7
--
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
TXAuth = mailing list
TXAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3D= AOvVaw0r39lH4qVOu0IQPJJYtSpI

= --Apple-Mail=_3C191AA5-CEB6-4A20-8341-F46F359AC7E8-- From nobody Sun Dec 13 00:16:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4273A1588 for ; Sun, 13 Dec 2020 00:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=DN3R8Gur; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JXlJ3RC6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3AOQXF715Ik for ; Sun, 13 Dec 2020 00:15:55 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087883A1396 for ; Sun, 13 Dec 2020 00:15:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 799EA5C00B5 for ; Sun, 13 Dec 2020 02:38:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 13 Dec 2020 02:38:43 -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=oT1Mp67BhDTJs72Y/mPRBO2wb4LiMKuGNC28Y4ykuUU=; b=DN3R8Gur +VlaHqlkhcGKWPZkLlhY364Z/4YSOqaoxBlVoj0tbLFiSQuuuCuuonK+isGrK8IT daUHEXFaKiZwdyKcztrDDBnYq7RYTzWSLXlTsYbHQUCPRUhfaQDFMnRWtGIRQYIq oqzOfR+z4dq9H8v2MlWc0grc3JgVv4w0WtsfscywUNIm2eWg+0BcC07Y8/QSeze/ EB4gCeLW3XF6n5N57Mf/yTjHiA98IKXlLweksSJmvhKTYqO1sYAHToUTMFIojn6a 3S+bO+ngoyDjvHszRNlXxA2lHfTEKTrANWs7LAuMAGnePbBYObWrY2FVBazLML7Q 6ZWwFML2Y6AcEA== 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=oT1Mp67BhDTJs72Y/mPRBO2wb4LiM KuGNC28Y4ykuUU=; b=JXlJ3RC6LowHSWeESYEafFM+8EOoj1PpBSPKRRR1aaHqM mcFtVYqVXhZLhl3i+DgP8XGIGHWFPMynklcERF2LeGz89txDb6ZoMXR/UNOIwGYc 0GgWLYoEhGz/WdXto6zp9ZBkGvh2UGrdZXQ56skE3UGiEQR2RdR2LNjlmpZ+UaK5 e4f3htOT2U174eBOWSKOqxqF8Pe1yFEsVu34qfSOSHIg2GW5A6VkYSrd81M4zQdf rfIKkK29OvU6/D2jXlCftTqpO+ap5LdGrlsKm8IHJEbXN1uPcFO4fyUKLj1w+Z1G H3j0fltIagyW5SgsQKJU7f0uCMpRBPT3XPNQBm9og== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekhedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedufedrjeejrdekuddrud eileenucevlhhushhtvghrufhiiigvpeejnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az184-911.internal.cloudapp.net (unknown [13.77.81.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 4FCA524005B for ; Sun, 13 Dec 2020 02:38:43 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6282257491737392820==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201213073843.4FCA524005B@mailuser.nyi.internal> Date: Sun, 13 Dec 2020 02:38:43 -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, 13 Dec 2020 08:15:57 -0000 --===============6282257491737392820== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+2/-0/=F0=9F=92=AC8) 2 issues created: - Are "locations" always URIs? (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/142=20 - Require return of "resources" in token response (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141=20 3 issues received 8 new comments: - #142 Are "locations" always URIs? (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/142=20 - #66 Continuation access token use outside of continuation requests (6 b= y fimbault, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/66=20 - #9 Clarify User-Code Interaction (1 by TomCJones) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/9=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+2/-0/=F0=9F=92=AC14) 2 pull requests submitted: - Pull test (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/144=20 - Replace 'MUST ... if possible' with SHOULD. (by mooreds) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/143=20 2 pull requests received 14 new comments: - #143 Replace 'MUST ... if possible' with SHOULD. (5 by jricher, mooreds= , yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/143=20 - #132 Changed "resource client (RC)" to "client instance" (9 by TomCJone= s, aaronpk, fimbault, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============6282257491737392820== 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 December 13, 2020

Events without label "editorial"

Issues

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

2 issues created:

3 issues received 8 new comments:

Pull requests

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

2 pull requests submitted:

2 pull requests received 14 new comments:

Repositories tracked by this digest:

--===============6282257491737392820==-- From nobody Sun Dec 13 01:06:33 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2C3A15FD for ; Sun, 13 Dec 2020 01:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLY42KkAsZsY for ; Sun, 13 Dec 2020 01:06:27 -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 665713A15FC for ; Sun, 13 Dec 2020 01:06:27 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id t9so12978209ilf.2 for ; Sun, 13 Dec 2020 01:06:27 -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=Q6CbNT1Ny6zXaDGX/0v0gcLh6pWf3efef8nETZc7UBc=; b=uNd5hQqipnlw6HqzofQx8uZTWNNtKVA297TY2M0bgzfejsHvHd64EkX1H+rI75Up6d OyKDz4p0W4i1kRgCyBI4/CmdZEl26jV3DHkPqLOaARNW17YgxGEFyoBOhhUiputcka7F oyQBaN80k2pJAJR7c44LS4fFvKdD3JylB7grkuUTPxgKlBh2fNKrfo3Dq8lTskmgW4hW jBTZTNAubiQp83FkTVKcVQODTaKJYH4RDOtQpU8bNeZJRQHWn7bjByO4yiQ+1INqY3kw vbodsBlv9ZwHjjyjnQF+8EM96H0wFDj+LMTZGf5Z5QEFOQwrHG5pjz94MaPSEh6gDazH sZNQ== 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=Q6CbNT1Ny6zXaDGX/0v0gcLh6pWf3efef8nETZc7UBc=; b=d3U5j3g/nIgxJphkc+PdsG1ZPNdZHxmXbi1AQN28BSrDugtdjaGOSSat5aNsBPL23f +QmpQ3vzIUTH8H1fcbCWTz8PeOVUgwZlDTpMC76SWhA83hQtkyrQfNK4bsYFOn5si5Qo OWWtm7n0weV0HJ6FsGNjPN9jHPU81niXzazYaXk3RMKsuS/zbgaijcDX3vpOoB95U6aP cTujABjwd4oDZSutkhRGcZO1feQfMACzdDm9bZOE3GZ3V/oJeKxTw5ge/ppLFkmpIcqn dCEhQHXUiU8p0Vy5s6OEYwler1msMCXFavz7NI0TCR55bg/V/jyrvf4mm9fkX5CQprE/ wq1g== X-Gm-Message-State: AOAM533seFyXMtP7aEUJtIN5dqDZLJkG4VWMW0GFdOsVv5Fj/KYCEoM4 o69XbiHmR7qcFgEt3AfS0ECz3SPDnVn9MhyxUbA= X-Google-Smtp-Source: ABdhPJxjlja2RfHfTz1W+Srm22cPnWCBF6O6QcwVZWF+3OF61DnL3m6TupLXQusJ3/53dmO0f8572JO3xEPC6NF1g0E= X-Received: by 2002:a92:6b05:: with SMTP id g5mr26590961ilc.289.1607850386503; Sun, 13 Dec 2020 01:06:26 -0800 (PST) MIME-Version: 1.0 References: <7f06d460-a4bb-652a-bba0-fe5fe5e6478f@free.fr> <56f50921-a88f-230a-20d1-aee187f09b6e@free.fr> <21cf7c30-c42a-f29c-a407-7badde5c0151@free.fr> In-Reply-To: From: Fabien Imbault Date: Sun, 13 Dec 2020 10:06:13 +0100 Message-ID: To: Denis Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000023bbc005b654d744" Archived-At: Subject: Re: [GNAP] RS-Token Introspection or RC-Token Introspection 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, 13 Dec 2020 09:06:33 -0000 --00000000000023bbc005b654d744 Content-Type: text/plain; charset="UTF-8" Hi Denis, I created https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 to follow up on that. Fabien On Fri, Dec 11, 2020 at 7:12 PM Fabien Imbault wrote: > Hi Denis, > > I agree that what you're saying makes sense. > > I'm just asking more broadly what people think of it (and trying to > balance the risks and benefits of each approach). > > Fabien > > On Fri, Dec 11, 2020 at 6:56 PM Denis wrote: > >> Hi Fabien, >> >> Hi Denis, >> >> Please note that the token introspection is not a new idea, it's already >> present in OAuth2 world (rfc 7662), and allows the RS to verify the access >> token. >> >> I am pretty aware that token introspection is already present in the >> OAuth2 world (rfc 7662). :-) >> >> In important point : RFC 7662 states "the contents of tokens are opaque >> to clients". >> The text does *not* state : "the contents of tokens are opaque to both >> clients and Resource Servers (RSs). >> >> In the current version of GNAP, there is also section 6 that introduces >> management endpoints, which could potentially be extended in a similar way >> (currently this is not specified, the management endpoint is here for >> rotation/revocation). Then the client could require more information on >> what is included in the opaque token, but of course, this relies on the >> assumption that the client trusts the AS. There is also the discussion on >> the "resource" description in the response, that may provide a simpler >> scheme (https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/141). >> >> But if we assume the AS may be malevolent (which is more likely if the AS >> becomes a less central point, at least for some implementations), >> then indeed receiving opaque tokens wouldn't provide all the guarantees, >> as it may lie on what is really in the token (too many claims for >> instance). >> >> >> More specifically, while I recon there might be a risk which we'd rather >> not have, I don't really think an opaque token is really an unmanageable >> issue with privacy. >> Suppose someone adds a field in a JWT, most likely you'll be able to >> detect that. >> >> RFC 7662 has been made available primarily for "lazy" RSs. :-) >> >> Let us consider a case where the contents of access tokens are opaque to >> both RCs and RSs. >> Let us suppose that opaque access tokens contains only a temporary handle >> to the set of claims related to the end-user, e.g. a 128 bits handle. >> >> Neither the RC, nor the RS would be able to understand it and the RS >> would be forced to call back the AS. >> Not only this call back will be bad in terms of the user's privacy >> because the AS will be able to know exactly when the access token has been >> used >> by the end-user but it would be impossible to detect it to prevent some >> damage on the RS side. >> We cannot assume that all future ASs in the world, while still providing >> the requested claims, will never deliver more attributes than the ones >> requested >> by the RC and thus allow RSs (and possibly other servers) link their >> users. >> >> >> But suppose we go for non opaque tokens, then we'd need a way of >> describing its format. Which might limit a bit the use cases if we're not >> careful. >> >> In OAuth 2.0, it has been possible to describe a token format (JSON Web >> Token (JWT) Profile for OAuth 2.0 Access Tokens). >> I don't believe it would a "mission impossible" in this WG to describe a >> GNAP format for access tokens. >> >> The IETF is supposed to standardize protocols at the bit level and this >> has made its success. >> >> Denis >> >> >> I'd be interested to know what others think, since it is diverging quite >> a bit from the OAuth2 world (not a bad thing in itself but still). >> >> Fabien >> >> On Fri, Dec 11, 2020 at 12:04 PM Denis wrote: >> >>> Hi Fabien, >>> >>> This is a response only to the point 7 from the "Quick review of >>> draft-ietf-gnap-core-protocol-00". >>> The full original text with your comments is copied after my reply. >>> >>> In order to allow the RC to understand the content of an opaque token, >>> you are proposing to support a Token Introspection query from the RC to the >>> AS. >>> This does not solve the concerns of a RC that wants to make sure that >>> the access token does not contain claims that have not been requested. >>> >>> Let us illustrate the case by using an example: >>> >>> The RC asks to the AS to deliver an access token that contains an >>> identifier only unique to the RS. >>> In reality, the AS delivers an access token that does contain an >>> identifier only unique to the RS >>> but in addition a globally unique identifier. Since the access token is >>> supposed to be opaque to the RC, >>> the RC calls the AS to perform a Token Introspection operation. In its >>> response, the AS presents an identifier >>> that is indeed only unique to the RS but the AS voluntarily *omits *to >>> present the globally unique identifier to the RC. >>> >>> In the same way, if Token Introspection is supported by a RS, that does >>> not provide confidence to the end-user or to the RC. >>> >>> Let us illustrate the case by using another example: >>> >>> The AS delivers to the RC an access token that only contains an >>> identifier unique to the RS. Since the access token >>> is supposed to be opaque to the RS, the RS calls the AS to perform a >>> Token Introspection operation. In its response, >>> the AS presents an identifier that is indeed only unique to the RS but >>> the AS voluntarily *adds *a globally unique identifier. >>> >>> *Conclusion*: In both cases, a globally unique identifier will be used >>> by the RS without the RC or the end-user knowing it. >>> Opaque tokens are in contradiction with the >>> end-user's privacy. >>> >>> For end-users caring about their privacy (or for systems willing to >>> protect the user's privacy), access tokens should not be considered >>> to be opaque to RCs, nor to RSs, and ASs should not support Token >>> Introspection, whether it is RS-Token Introspection or RC-Token >>> Introspection. >>> >>> Denis >>> >>> >>> 7. The content and the format of access tokens shall not be considered >>>>>> to be opaque to the RC so that the RC can inspect it. >>>>>> This is a matter of confidence to make sure for the RC (and for >>>>>> the user) that no "extra" information has been included by the AS into the >>>>>> access token. >>>>>> >>>>> [FI] This might go a bit further than the GNAP's mandate (especially >>>> if it becomes a mandatory requirement). But supposing we support non-opaque >>>> tokens, >>>> does it preclude supporting opaque tokens? It's just a different trust >>>> model, which makes sense if people agree with your premises (previous >>>> items), >>>> but that are less relevant if people still consider the AS as the >>>> central piece. Also one great thing with opaque tokens is that it makes the >>>> system easier to upgrade >>>> (you don't really care about what a token is). >>>> >>>> [Denis] Privacy is not more relevant for an AS-centric model than for a >>>> RS-centric model. In particular, a RC should be able to verify which kind >>>> of end-user identifier claim >>>> has been incorporated into the access token by the AS, in particular >>>> whether it is globally unique, unique to the AS only, unique to the RS only >>>> or ephemeral (valid for >>>> that RS during a session with the AS). >>>> >>> [FI2] ok, see discussion on whether tokens should be opaque or not. >>> >>>> I suppose that the use of structured access tokens should be >>>> recommended. This means,in particular, that from the very beginning, we >>>> should incorporate a version number >>>> inside each access token. >>>> >>>> One alternative way would be to allow RS call to AS for verification >>>> (including revocation status) and include a checksum. >>>> >>>> [Denis] The RC, i.e. not the RS, should be able to perform such >>>> verification before presenting the access token to the RS. So this >>>> alternative way would not work. >>>> >>> [FI2] then there could be a similar API for the client (cf discussion on >>> similarities between introspection/management APIs). >>> >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --00000000000023bbc005b654d744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Denis,=C2=A0


Fabien

On Fri, Dec 11, 2020 at 7:12 PM F= abien Imbault <fabien.imbaul= t@gmail.com> wrote:
Hi Denis,=C2=A0

I agree that= what you're saying makes sense.=C2=A0

I'm= just asking more broadly what people think of it (and trying to balance th= e risks and benefits of each approach).=C2=A0

Fabi= en

On Fri, Dec 11, 2020 at 6:56 PM Denis <denis.ietf@free.fr> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> =20 =20 =20
Hi Fabien,

=20
Hi Denis,=C2=A0

Please note that the token introspection is not a new idea, it's already present in OAuth2 world (rfc 7662), and allows the RS to verify the access token.

I am pretty aware that token introspection is already present in the OAuth2 world (rfc 7662). :-)

In important point : RFC 7662 states "the contents of tokens ar= e opaque to clients".
The text does not state : "the contents of tokens are opaque to both clients and Resource Servers (RSs).


In the current version of GNAP, there is also section 6 that introduces management endpoints, which could potentially be extended in a similar way (currently this is not specified, the management endpoint is here for rotation/revocation). Then the client could require more information on what is included in the opaque token, but of course, this relies on the assumption that the client trusts the AS.=C2=A0There is also the discussion on the "resource= " description in the response, that may provide a simpler scheme (https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/issues/141).=C2=A0
=C2=A0
But if we assume the AS may be malevolent=C2=A0(which is mor= e likely if the AS becomes a less central point, at least for some implementations),
then indeed receiving opaque tokens wouldn't provide all th= e guarantees, as it may lie on what is really in the token (too many claims for instance).

More specifically, while I recon there might be a risk which we'd rather not have, I don't really think an opa= que token is really an unmanageable issue with privacy.
Suppose someone adds a field in a JWT, most likely you'll b= e able to detect that.

RFC 7662 has been made available primarily for "lazy" RSs.= :-)

Let us consider a case where the contents of access tokens are opaque to both RCs and RSs.

Let us suppose that opaque access tokens contains only a temporary handle to the set of claims related to the end-user, e.g. a 128 bits handle.

Neither the RC, nor the RS would be able to understand it and the RS would be forced to call back the AS.
Not only this call back will be bad in terms of the user's privac= y because the AS will be able to know exactly when the access token has been used
by the end-user but it would be impossible to detect it to prevent some damage on the RS side.

We cannot assume that all future ASs in the world, while still providing the requested claims, will never deliver more attributes than the ones requested
by the RC and thus allow RSs (and possibly other servers) link their users.

But suppose we go for non opaque tokens, then we'd need = a way of describing its format. Which might limit a bit the use cases if we're not careful.

In OAuth 2.0, it has been possible to describe a token format (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens).
I don't believe it would a "mission impossible" in this= WG to describe a GNAP format for access tokens.

The IETF is supposed to standardize protocols at the bit level and this has made its success.

Denis


I'd be interested to know what others think, since it is diverging quite a bit from the OAuth2 world (not a bad thing in itself but still).=C2=A0

Fabien

On Fri, Dec 11, 2020 at 12:04 PM Denis <denis.ietf@free.fr> wrote:
Hi Fabien,

This is a response only to the point 7 from the "Quick review of draft-ietf-gnap-core-protocol-00"= ;.
The full original text with your comments is copied after my reply.

In order to allow the RC to understand the content of an opaque token, you are proposing to support a Token Introspection query from the RC to the AS.
This does not solve the concerns of a RC that wants to make sure that the access token does not contain claims that have not been requested.

Let us illustrate the case by using an example:

The RC asks to the AS to deliver an access token that contains an identifier only unique to the RS.
In reality, the AS delivers an access token that does contain an identifier only unique to the RS
but in addition a globally unique identifier. Since the access token is supposed to be opaque to the RC,
the RC calls the AS to perform a Token Introspection operation. In its response, the AS presents an identifier
that is indeed only unique to the RS but the AS voluntarily omits to present the globally unique identifier to the RC.

In the same way, if Token Introspection is supported by a RS, that does not provide confidence to the end-user or to the RC.

Let us illustrate the case by using another example:

The AS delivers to the RC an access token that only contains an identifier unique to the RS. Since the access token
is supposed to be opaque to the RS, the RS calls the AS to perform a Token Introspection operation. In its response,
the AS presents an identifier that is indeed only unique to the RS but the AS voluntarily adds a globally unique identifier.

Conclusion: In both cases, a globally unique identifier will be used by the RS without the RC or the end-user knowing it.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Opaque t= okens are in contradiction with the end-user's privacy.

For end-users caring about their privacy (or for systems willing to protect the user's privacy), access tokens should not be considered
to be opaque to RCs, nor to RSs, and ASs should not support Token Introspection, whether it is RS-Token Introspection or RC-Token Introspection.

Denis


7. The content and the format of access tokens shall not be considered to be opaque to the RC so that the RC can inspect it.
=C2=A0=C2=A0=C2=A0 This is a matter= of confidence to make sure for the RC (and for the user) that no "extra" information has b= een included by the AS into the access token.

[FI] This might go a bit further than the GNAP's=C2=A0mandat= e (especially if it becomes a mandatory requirement). But supposing we support non-opaque tokens,
does it preclude supporting opaque tokens? It's just a different trust model, which makes sense if people agree with your premises (previous items),
but that are less relevant if people still consider the AS as the central piece. Also one great thing with opaque tokens is that it makes the system easier to upgrade
(you don't really care about what a token is).

[Denis] Privacy is not more relevant for an AS-centric model than for a RS-centric model. In particular, a RC should be able to verify which kind of end-user identifier claim
has been incorporated into the access token by the AS, in particular whether it is globally unique, unique to the AS only, unique to the RS only or ephemeral (valid for
that RS during a session with the AS).

[FI2] ok, see discussion on whether tokens should be opaque or not.

I suppose that the use of structured access tokens should be recommended. This means,in particular, that from the very beginning, we should incorporate a version number
inside each access token.


One alternative way would be to allow RS call to AS for verification (including revocation status) and include a checksum.

[Denis]=C2=A0 The RC, i.e. not the RS, should be abl= e to perform such verification before presenting the access token to the RS. So this alternative way would not work.

[FI2] then there could be a similar API for the client (cf discussion on similarities between introspection/management APIs).


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


--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000023bbc005b654d744-- From nobody Sun Dec 13 03:20:50 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE423A168A for ; Sun, 13 Dec 2020 03:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAZ3lzcJDVEp for ; Sun, 13 Dec 2020 03:20:43 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2D83A1689 for ; Sun, 13 Dec 2020 03:20:43 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id p5so13132446ilm.12 for ; Sun, 13 Dec 2020 03:20:43 -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=Pt1AeWFi0t6hUaqCBpIrOOX29H6mg3ea6Rf/4PnNEik=; b=stpVb1lIrZwqor8E3KRr5/B8MjI2/FYDfucY19PJtVDEdiPuJKLcrPiRibt3vRsH6B ++cSx0+VsQWP03j4YLtZju4F1y6cHVdXUSslQi/TqPOXTJrOgswseK+rzOIpFFFSPB/I 0QwP9r+isiDCmdD6DzjBuEH7rCY5Xg7emqsRq/xKRiwSPmKnhao1Fs3zi/ykrArybhNO 1ZMeSuBjQs8zvhh6pRrGA1ctuafBciiB/Mouo2fsoqhPFEdxvDObjc+fnrw8GJ07pWdr FMq2zb2T0oNk6kHb3ZpSLioRvhT5jhK8yuJrfyqZ3cN0Om0GYS4xjHjpMqA8L2HVC4m7 SkAA== 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=Pt1AeWFi0t6hUaqCBpIrOOX29H6mg3ea6Rf/4PnNEik=; b=nSSfmJOlGiz/v4LGuGlPMz7splqDUgv//LBoZ98iFBPqEzobSq4iSzyxoob2/rOXbK F5yZPPz0kImdg95SCaHc4lYeX6YtVdimfeje5oWchj/aIuh14FDN0yZ+Nm6ki8w9dzOr UfD7l4nRLFfU/PswwvNgcp/YSV7KNrxIsERD9Dt9NCo1QUzqNvd+op4TUlgNbpNhe1NL OPW5TPRvkQTJT6hK3kiBohOClhQ9KIfQ5rrBYQfXWMCgJuAPc4VTCIeD9anndJ93AQeJ XafiYKJgqX3rhXDWk6zwPGEuEbtVCTWqPGRq86U/lzqRJfMavzUpOhq5LFVqesBJ16cc jTiQ== X-Gm-Message-State: AOAM531MxRxSyf1FuUq/CXuaKkyHKT+iKr5S80m2pnT7bUCAF9c0h1Qc IbOVuEYEuTnptnhI9wfc5GsTlpZFF2eJY/Tj0Kc= X-Google-Smtp-Source: ABdhPJysy5WCtekedoD2/RQIWa0rdVY6/We2auW0NtmmOJMNke/1Qq46pLnhkXLKUdQ+OVhfhms4e3dM5x/HPy7RDDo= X-Received: by 2002:a92:ce44:: with SMTP id a4mr28999822ilr.178.1607858442384; Sun, 13 Dec 2020 03:20:42 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> In-Reply-To: From: Fabien Imbault Date: Sun, 13 Dec 2020 12:20:29 +0100 Message-ID: To: Yaron Sheffer Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000004eb9f105b656b7a3" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 11:20:48 -0000 --0000000000004eb9f105b656b7a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, We're at the end of the 2 week period, and so I integrated the various feedbacks : a) from Yaron's feedback, removed new term "IS" and update issue https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle the proposal here b) integrated Tom's feedback regarding the RO (and moved to access token) c) definitions follow an ISO style as suggested by Denis, which we took as a starting point (but I made the modifications I felt were necessary) I modified the definitions, notes and examples as a consequence. You'll also find a summary of discussions for each term, so that we can keep track of them too. My biggest question is : what should we use as our main vocabulary between privilege/rights/attribute? I tried to clarify, please let me know what you think. The general idea is that we grant privileges that are delivered under the form of access tokens (which contain rights and/or attributes). Regarding whether access tokens should be opaque or not, I suggest to remove that from the definition and handle that in issue https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 All has been consolidated on the wiki too https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so that we have a clearer view of where we stand. Please comment further on the list if you have comments, I'll update if necessary (and refer to the mailing list url in the comment of the wiki update, from now on). Then editors will review the proposal. Here is a copy of https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology#latest-= discussion-update . Latest discussion update Here we consolidate the latest proposal(s) from the group. We also include the discussion items (individual feedbacks). Authorization Server (AS) - Definition: server that grants privileges to a particular end-user and that provides them to a client in the form of an access token Feedbacks / discussion / questions : - Suggested "privilege" definition (that we would probably add as an additional sub-entry): "A privilege is the right to perform an operation (or action) on a Resource." See also other def - Note that we don't include claims in the definition (cf OIDC/SSI integration), but since we talk about a "particular end-user" it is assu= med somehow - Denis suggested we used "rights and attributes" instead of privileges. [FI] However i don't think one can really speak about granting attribute= s, except indirectly (ABAC). See access token for more on that, where we ca= n be more specific. - Do we allow cases such as distributing the AS on a mobile? (in this case we're at the limit of what we call a server) Client - Definition: application used by an end-user to interact with an AS or a RS - Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of a single piece of client software. - Example: a client can be a mobile application, a web application, etc. Feedbacks / discussion : - Replaces previously proposed RC, we wouldn't provide a short name. - Keep OAuth2 term, but we clarify it - Further discussion on Client instance Resource Server (RS) - Definition: server that denies operations on protected resources, unless the client provides valid access tokens issued by an AS Feedbacks / discussion : - Denis suggests to make explicit that we could have several ASs - "issued by one or more ASs" (also we'd need a convention on how to denot= e plural, e.g. ASs). Not exactly sure right now of the multiple issuance would work, so needs to be clarified. Also not sure if that's even necessary (do we lack in generality if we keep the singular?) Resource Owner (RO) - Definition: physical person acting on its own or representing an organization, that may grant privileges on resources he has authority up= on - Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules). Feedbacks / discussion - As some point we suggested "The RO may decide to remove its consent at any time." Tom provided useful feedback on that. Moved to access token where it fits more naturally. End-user - Definition: physical person that operates with the client software - Note: that physical person may or may not be the same entity as the RO Access token - Definition: digitally signed data that contains specific rights and/or attributes - Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed. The AS usually provides a method for the RO to revoke the privileges at any point in ti= me. - Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound tok= en) Feedbacks / discussion - Would require the subdefinitions right: ability for an end-user to perform a given operation (or action) on a resource (or object) under th= e control of a RS / attribute: property related to an end-user. - Note 2 is here in relationship with PR 129 Grant - Definition (verb): to permit, as a privilege given to an end-user to exercise some rights and/or assert attributes during a specific duration - Definition (noun): the act of granting Ke= y - Definition: public cryptographic binding a request to the holder of a private key, used by the protocol entities (AS, RS, client instance, bou= nd token, etc.) to identify themselves. - Note: a key can be rotated or revoked by its holder. The protocol supports the update of the key information. Feedbacks / discussion - Denis thinks the term "key" is well understood and doesn't need to be defined. Yet, I tend to believe we'd gain to keep it. First the generic term "key" may be many things : symmetric/asymmetric, public/private, et= c. It's also useful to explain its use in the protocol Resource - Definition: protected API served by a RS and accessed by a client, if and only if a valid access token is provided On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault wrote: > Hi Yaron, > > Yes I highlighted that this was a new term. We can deal with it as a > separate issue indeed. > > Best > Fabien > > On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer > wrote: > >> Hi Fabien, >> >> >> >> Yes, we definitely need to reach closure on terminology, thank you for >> driving this discussion! >> >> >> >> One process comment: unless I=E2=80=99m missing something, the Interact = (or >> Interaction) Server is not mentioned in the current draft. I suggest we = do >> not introduce new functional components or new behaviors as part of the >> terminology discussion. Specifically, if the IS is useful, let=E2=80=99s= reach >> consensus on that separately. Then we can add it into the Terminology >> section. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *TXAuth on behalf of Fabien Imbault < >> fabien.imbault@gmail.com> >> *Date: *Friday, December 11, 2020 at 14:31 >> *To: *Denis >> *Cc: *GNAP Mailing List >> *Subject: *Re: [GNAP] Terminology proposal >> >> >> >> Hi Denis, >> >> >> >> Thanks for your detailed feedback. My comments are embedded into your >> message. Again those comments are my own, and we'll need to converge to >> some consensus beyond what I say here. My main open question is really >> about the RO being optional. Could you explain? >> >> >> >> Fabien >> >> >> >> On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: >> >> This is a global response to the definitions proposal. >> >> >> TerminologyI propose to adopt the way ISO defines how to write the >> definitions.It is a *single sentence* that may be substituted to the >> wording being defined in the context of a sentence that uses that >> definition. >> Since this single sentence can be substituted to the wording, there is >> not point at the end of that sentence. The sentence does not >> have a "a" or "the" in front of it. >> >> >> >> [FI] In the first version, I was mostly trying to not get too far away >> from the current text. But yes that's a good idea, it gives a more >> formal rule, which has been proven to work. >> >> >> >> If more information is useful to understand the wording, it is placed in >> one or more notes afterwards. >> >> >> >> Note: The ISO rules for drafting definitions are in the ISO/IEC >> Directives, Part 2 (edition 2018): >> >> 16.5.6 Definitions >> >> The definition shall be written in such a form that it can replace the >> term in its context. It shall not start with an article (=E2=80=9Cthe=E2= =80=9D, =E2=80=9Ca=E2=80=9D) nor >> end with a full stop. >> A definition shall not take the form of, or contain, a requirement. >> >> Only one definition per terminological entry is allowed. If a term is >> used to define more than one concept, a separate terminological entry sh= all >> be created >> for each concept and the domain shall be included in angle brackets >> before the definition. >> >> Circular definitions, which repeat the term being defined, are not >> allowed. >> >> Comments are inserted between the lines. >> >> >> >> Hello everyone, >> >> >> >> As an editor : a quick reminder that terminology issues will be discusse= d >> in the coming weeks, and we're expecting your inputs right now (accordin= g >> to the process previously sent on the mailing list). >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> >> >> >> The rest of this message is a proposal written in my own name, and >> doesn't involve discussions with the editors/chairs who might have >> different opinions. >> Authorization Server (AS) >> >> Manages the granting of privileges to a third-party client instance. If >> the RO consents to at least a part of what is requested, the AS issues a= n >> access token to the client. >> >> *My questions: * >> >> *- was else do we issue? (e.g. id claims, payment info, etc.) We could >> have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D= is not clear. I >> removed that for now.* >> >> *- there might potentially be several AS, currently we don=E2=80=99t ref= lect that >> anywhere. If would leave that as an open item, depending on what we end = up >> doing in the spec* >> >> I am not in favour of this definition: A RO as defined later: "authorize= s >> the request to access a protected resource from the RS to the client". >> This does not mean in any way that a RO has necessarily a direct >> relationship with one or more ASs. [FI] indeed we could remove that >> limitation, to have a more general definition >> Using the ISO style for definitions, I propose: >> >> Authorization Server (AS): server that grants rights and/or attributes t= o >> a particular end-user and that provides them to a client in the form of = an >> access token >> >> Since this definition is using the words "rights" and "attributes", >> these two terms need to be defined as well. >> >> right: ability for an end-user to perform a given operation on an object >> under the control of a RS >> >> attribute: property related to an end-user >> >> >> >> [FI] I like your proposal in general. There might be some discussions on >> the details. I don't think it makes sense to grant "attributes". >> >> Some explanations: a "right" is able to support a capability scheme. An >> "attribute" is able to support an ACL scheme. >> >> These two schemes are able to support "discretionary access control" >> where the end-user has a "need-to-know". >> >> However, some attributes are also able to support what was called in th= e >> past "mandatory access control"; for example, >> >> if the end-user is cleared to "top-secret / marketing strategy". >> >> >> >> Interact Server (IS) - this is a new proposed term >> >> Manages the front-end interaction with the RO, in order to gather its >> consent. Depending on the deployment model and the privacy requirements, >> the IS may be a component of the AS, or may be distinct and managed by >> another party. >> >> Example : an IS usually involves a web interface accessed by RO through = a >> web browser. >> >> Note : an IS is not always required, especially if the access is granted >> through automated policies. >> >> Using the ISO style for definitions, I propose: >> >> >> >> Interact*ion* Server (IS) >> >> component from the AS or server interfacing with an AS that manages the >> interactions with a RO, in order to gather its authorizationNote : since >> the RO is an optional component, the IS is also an optional component. >> >> >> >> [FI] indeed IS is optional. note for myself when looking at RO : why is >> RO optional ? >> >> Client Requests privileges from the AS, and uses access tokens at the >> RS. This specification differentiates between a specific instance (the >> client instance, identified by its unique public key) >> and the software running the instance (the client software). . For some >> kinds of client software, there could be many instances of a single piec= e >> of client software. >> The AS determines which policies apply to a given client instance, >> including what it can request and on whose behalf. >> >> Some comments: The above text is stating: "(the client instance, >> identified by its unique public key)". >> A client instance may use a public key, but that key is not necessarily >> unique, in particular when there are multiple ASs. >> >> [FI] yes, although when possible I would still consider a better practic= e >> to expose a key to a specific AS and not to the entire set of available >> ASs. >> >> Example : a client can be a mobile application or a web application (the >> client software) that requires authorizations from the RO to retrieve >> content from various protected APIs. The client instance may for instanc= e >> refer to a specific version of that client software. >> >> *See on-going discussion : >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 >> (client >> instance). * >> >> Using the ISO style for definitions, I propose: >> >> Client: application used by an end-user to interact with an AS or a RS >> >> Note: a client can be a mobile application or a web application [FI] for >> me those are just examples, because there could me more (ex IoT device) >> >> [FI] you remove the entire discussion on client instance / client >> software, is that on purpose because you think it's not useful/right, or= is >> it because of something else? (maybe add your comment of the related >> issue) >> >> Resource Server (RS) >> >> Accepts valid access tokens from the client issued by the AS and serves >> protected resources on behalf of the RO. There could be multiple RSs >> protected by the AS that the client may call. >> >> Example : a RS is often composed of protected APIs that can be consumed >> by authorized client software. >> >> One comment: a RO is not necessarily involved. [FI] a bit hard to >> imagine, there's some kind of owner. Could you be more explicit? >> Using the ISO style for definitions, I propose: >> >> Resource Server (RS): server that accepts valid access tokens from >> clients issued by one or more ASs which are used to grant or deny some >> requested operations >> >> Note: a RS is often composed of protected APIs that can be consumed by >> clients. >> >> >> >> Resource Owner (RO) >> >> Authorizes the request to access a protected resource from the RS to the >> client. The RO may decide to remove its consent at any time. >> >> Note : the RO may be a physical person or may represent an organization. >> >> >> >> Two comments: In order to avoid confusion with the end-user consent, the >> word " authorization" is being used instead of "consent". [FI] ok >> >> It should be said that the RO is an optional component. [FI] why? Using >> the ISO style for definitions, I propose: >> >> Resource Owner (RO): physical person acting on its own or representing a= n >> organization that authorizes to clients operations on protected resource= s >> from a RS >> >> Note: The RO is an optional component that may interact either with one >> RS or with one or more ASs ,e.g. using an IS. >> >> End-user =E2=80=93 this was previously Requesting Party RQ >> >> A physical person that operates and interacts with the client software. >> >> Note : the end-user may or may not be the same entity as the RO. >> >> The Note is slightly incorrect. the *physical person* may or may not be >> the same entity as the RO. [FI] I didn't understand your comment >> Using the ISO style for definitions, I propose: >> >> End-user : physical person that operates and interacts with the client >> software >> >> Note : that physical person may or may not be the same entity as the RO. >> >> >> >> Access Token >> >> A set of privileges delegated to the client instance for a specific >> end-user. An access token is created by the AS, consumed and verified by >> the RS, and issued to and carried by the client's end-user on behalf of = the >> RO. The contents and format of the access token are opaque to the client= . >> >> Example : JWT is a commonly used format. >> >> Note 1 : an access token generally has a limited duration, after which i= t >> may be refreshed at a regular interval. >> >> Note 2 : an access token may be revoked at any time by the RO. >> >> Note 3 : an access token may act as a capability or require an additiona= l >> authentication by binding to a key >> >> A fundamental point: the third sentence from the definition states: "The >> contents and format of the access token are opaque to the client". >> >> [FI] I'll check your other thread dedicated to that issue >> >> See my other email sent today about "RS-Token Introspection or RC-Token >> Introspection" where I conclude: >> >> For end-users caring about their privacy (or for systems willing t= o >> protect the user's privacy), access tokens should not be considered >> to be opaque to RCs nor to RSs and ASs should not support Token >> Introspection, whether it is RS-Token Introspection or RC-Token >> Introspection. >> >> The example and the other Notes above should be removed. If needed they >> should be placed in the main body of the document. >> >> Using the ISO style for definitions, I propose: >> >> Access Token : digitally signed data issued by an Authorization Server >> (AS) and consumed by a Resource Server (RS) >> that contains rights and/or attributes granted >> to a particular end-user >> >> >> >> Grant >> >> The process by which the client requests and is given delegated access t= o >> the RS by the AS through the authority of the RO. >> >> Using the ISO style for definitions, I propose: >> >> Grant: permission given to end-user to use a subset of his rights and/or >> his attributes at a specific time and for a specific duration >> >> >> >> Key >> >> A public cryptographic binding a request to the holder of a private key. >> Access tokens and client instances can be associated with specific keys = at >> a point in time. >> >> Note : a key can be rotated or revoked by its holder. The protocol >> supports the update of the key information. >> >> "key" is a general term that is well understood and that does not need t= o >> be defined. [FI] I really wouldn't bet on that. We can reuse an existing >> definition but it is a central piece so we need to be explicit >> >> The "definitions" section is not intended to explain what can be done >> with the term that is being defined. [FI] ok we can work on that >> Until the word "key" is qualified using one or more other terms, this >> definition should be removed. >> >> >> >> Resource >> >> A protected API served by the RS and accessed by the client if and only >> if access has been granted. Access to this resource is delegated by the = RO >> as part of the grant process. >> >> The second sentence of the definition is not in accordance with the ISO >> style or definitions and furthermore this second sentence should be remo= ved >> since a RO is an optional element. >> >> >> Using the ISO style for definitions, I propose: >> >> Resource: protected API served by a RS and accessed by a client, if and >> only if access is granted by an access token >> >> Subject Information >> >> Information about a subject (usually a RO) that is returned directly to >> the client from the AS. >> >> Note : this information needs to be unique. >> >> >> >> This definition exhibits several problems: >> >> (1) The term "subject" is not defined. >> >> (2) The information that is returned is for an end-user, i.e. not for "(= usually >> a RO)". >> >> (3) The Note states : "this information needs to be unique". Does it mea= n >> unique for the AS ? globally unique ? >> >> This definition should be revisited. [FI] I agree (I myself had many >> questions here) >> >> Denis >> >> >> >> *My questions : * >> >> *- probably we=E2=80=99d need to define subject* >> >> *Subject : >> https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subjec= t+Dictionary+Entry >> * >> >> *- might be useful to clarify the relationship to what identity provider= s >> do * >> >> >> >> >> >> 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 >> > --0000000000004eb9f105b656b7a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,=C2=A0

We're at the = end of the 2 week period, and so I integrated the various feedbacks :=C2=A0=

a) from Yaron's feedback, removed new term &q= uot;IS" and update issue=C2=A0https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/133 to handle the proposal here=C2=A0
b) int= egrated Tom's feedback regarding the RO (and moved=C2=A0 to access toke= n)
c) definitions follow an ISO style as suggested by Denis, = which we took as a starting point (but I made the=C2=A0modifications I felt= were necessary)

I modified the definitions, notes= and examples as a consequence. You'll also find a summary of discussio= ns for each term, so that we can keep track of them too.

My biggest question is : what should we use as our main vocabulary b= etween privilege/rights/attribute? I tried to clarify, please let me know w= hat you think. The general idea is that we grant privileges that are delive= red under the form of access tokens (which contain rights and/or attributes= ).
Regarding whether access tokens should be opaque or not, I sug= gest to remove that from the definition and handle that in issue=C2=A0https:= //github.com/ietf-wg-gnap/gnap-core-protocol/issues/145

<= /div>
All has been consolidated on the wiki too=C2=A0https://githu= b.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so that we have = a clearer view of where we stand.=C2=A0

Please com= ment further on the list if you have comments,=C2=A0I'll update if nece= ssary (and refer to the mailing list url in the comment of the wiki update,= from now on). Then editors will review the proposal.=C2=A0
Here = is a copy of=C2=A0https://github.com/ietf-wg-= gnap/gnap-core-protocol/wiki/Terminology#latest-discussion-update.

Latest discuss= ion update

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

<= /a>Authorization Server (AS)

Feedbacks / discussion / questions :
  • Suggested "privilege" definition (that we would probably= add as an additional sub-entry): "A privilege is the right to perform= an operation (or action) on a Resource." See also=C2=A0other def
  • Note that we don't include claims= in the definition (cf OIDC/SSI integration), but since we talk about a &qu= ot;particular end-user" it is assumed somehow
  • Denis suggested we used "rights and = attributes" instead of privileges. [FI] However i don't think one = can really speak about granting attributes, except indirectly (ABAC). See a= ccess token for more on that, where we can be more specific.
  • Do we allow cases such as dist= ributing the AS on a mobile? (in this case we're at the limit of what w= e call a server)

Client

  • D= efinition: application used by an end-user to interact with an AS or a RS
  • Note: this specifi= cation differentiates between a specific instance (the client instance, ide= ntified by its public key) and the software running the instance (the clien= t software). For some kinds of client software, there could be many instanc= es of a single piece of client software.
  • Example: a client can be a mobile application, a we= b application, etc.

Feedbacks / discussion :

  • Replaces previously proposed = RC, we wouldn't provide a short name.
  • Keep OAuth2 term, but we clarify it
  • Further discussion on=C2=A0Client instance

Resource Server (RS)

  • Definition: server that denies ope= rations on protected resources, unless the client provides valid access tok= ens issued by an AS

Feedbacks / discussion :

  • Denis suggests to make ex= plicit that we could have several ASs - "issued by one or more ASs&quo= t; (also we'd need a convention on how to denote plural, e.g. ASs). Not= exactly sure right now of the multiple issuance would work, so needs to be= clarified. Also not sure if that's even necessary (do we lack in gener= ality if we keep the singular?)

Resource Owner (RO)

  • Definition: physical person = acting on its own or representing an organization, that may grant privilege= s on resources he has authority upon
  • Note: the act of granting privileges may be manual (i.e= . through an interaction) or automatic (i.e. through predefined rules).

Feedbacks / disc= ussion

  • As some point we suggested "The RO may decide to re= move its consent at any time." Tom provided=C2=A0useful feedback=C2=A0on that. Moved to access token wher= e it fits more naturally.

End-user<= /h2>
  • Definition: physical person that operates with the client softw= are
  • Note: that ph= ysical person may or may not be the same entity as the RO

Access token

  • Definition: digital= ly signed data that contains specific rights and/or attributes
  • Note 1: the access token can = be issued to an end-user (usually requiring his authentication) and subsequ= ently refreshed. The AS usually provides a method for the RO to revoke the = privileges at any point in time.
  • Note 2: an access token may act as a capability (i.e. beare= r token) or require an additional authentication by binding to a key (i.e. = bound token)

= Feedbacks / discussion

  • Would require the subdefinitions rig= ht: ability for an end-user to perform a given operation (or action) on a r= esource (or object) under the control of a RS / attribute: property related= to an end-user.
  • = Note 2 is here in relationship with=C2=A0PR 129

Grant

    Definition (verb): to permit, as a privil= ege given to an end-user to exercise some rights and/or assert attributes d= uring a specific duration
  • Definition (noun): the act of granting

= Key

  • Definition: public cryptographic binding a request to t= he holder of a private key, used by the protocol entities (AS, RS, client i= nstance, bound token, etc.) to identify themselves.
  • Note: a key can be rotated or revoked by= its holder. The protocol supports the update of the key information.
    • <= /ul>

    Feedbacks / di= scussion

    • Denis thinks the term "key" is well understo= od and doesn't need to be defined. Yet, I tend to believe we'd gain= to keep it. First the generic term "key" may be many things : sy= mmetric/asymmetric, public/private, etc. It's also useful to explain it= s use in the protocol

    Resource

    =
    • Definition: protected API served by a RS and accessed by a client, = if and only if a valid access token is provided

On Fri, Dec = 11, 2020 at 6:05 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi Yaron,=C2=A0

<= /div>
Yes I highlighted that this was a new term. We can deal with it a= s a separate issue indeed.=C2=A0

Best
Fa= bien

On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer <yaronf.ietf@gmail.com> w= rote:

Hi Fabien,

=C2=A0

Yes, we defin= itely need to reach closure on terminology, thank you for driving this disc= ussion!

=C2=A0

One process comment: unless I=E2=80=99m missing somethi= ng, the Interact (or Interaction) Server is not mentioned in the current dr= aft. I suggest we do not introduce new functional components or new behavio= rs as part of the terminology discussion. Specifically, if the IS is useful= , let=E2=80=99s reach consensus on that separately. Then we can add it into= the Terminology section.

= =C2=A0

Thanks,

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

=C2=A0

Fro= m: TXAuth <txauth-bounces@ietf.o= rg> on behalf of Fabien Imbault <fabien.imbault@gmail.com>
Date: = Friday, December 11, 2020 at 14:31
To: Denis <denis.ietf@free.fr>
<= b>Cc: GNAP Mailing List <txauth@ietf.org>
Subject: Re: [GNAP] Terminolo= gy proposal

=C2=A0

Hi Denis,=C2=A0

=C2=A0

<= div>

Thanks for your detailed feedback. My comments a= re embedded into your message. Again those comments are my own, and we'= ll need to converge to some consensus beyond what I say here. My main open = question is really about the RO being optional. Could you explain?

=C2=A0

Fabien=C2=A0

=C2=A0

On= Fri, Dec 11, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:

This is a globa= l response to the definitions proposal.

=C2=A0

Terminology=

<= span style=3D"font-size:12pt;font-family:Arial,sans-serif;color:rgb(36,41,4= 6);font-weight:normal">I propose to adopt the way ISO defines how to write = the definitions.

It is a <= span style=3D"font-size:12pt;font-family:Arial,sans-serif;color:rgb(36,41,4= 6)">single sentence that may be substitu= ted to the wording being defined in the context of a sentence that uses tha= t definition.
Since this single sentence can be substituted to the word= ing, there is not point at the end of that sentence. The sentence does not =
have a "a" or "the" in front of it.

=C2= =A0

[= FI]=C2=A0In the first version, I was mostly trying to not get too far away = from the current text.=C2=A0But=C2= =A0yes that's a good idea, it gives a more fo= rmal rule, which has been proven to work.=C2=A0

=C2=A0

I= f more information is useful to understand the wording, it is placed in one= or more notes afterwards.

=C2=A0

Note: The ISO = rules for drafting definitions are in the ISO/IEC Directives, Part 2 (editi= on 2018):

16.5.6=C2=A0=C2=A0=C2=A0 Definitio= ns

The definition shall be written in such= a form that it can replace the term in its context. It shall not start wit= h an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end with a fu= ll stop.
A definition shall not take the form of, or contain, a require= ment.

Only one definition per terminological entry is allowed. If a = term is used to define more than one concept, a separate terminological ent= ry shall be created
for each concept and the domain shall be included i= n angle brackets before the definition.

Circular definitions, which = repeat the term being defined, are not allowed.

Comments are inserted between the lines.

=C2=A0

Hello = everyone,=C2=A0

=C2=A0=

As an editor : a quick reminde= r that terminology=C2=A0issues will be discussed in the coming weeks, and w= e're expecting your inputs right now (according to the process previous= ly sent on the mailing list).

= =C2=A0

The rest of this message= is a proposal written in my own name, and doesn't involve discussions = with the editors/chairs who might have different opinions.=C2=A0 =

Authorization Server (A= S)

Manag= es the granting of privileges to a third-party client instance. If the RO c= onsents to at least a part of what is requested, the AS issues an access to= ken to the client.

My questions:

- was else do we issue? (e.g. id claims, payment= info, etc.) We could have more than access tokens, but =E2=80=9Cdirected i= nformation=E2=80=9D is not clear. I removed that for now.=

- there might poten= tially be several AS, currently we don=E2=80=99t reflect that anywhere. If = would leave that as an open item, depending on what we end up doing in the = spec

I am not in favour of this definition:= A RO as defined later: "authorizes the request to access a protected = resource from the RS to the client".
This does not mean in any way= that a RO has necessarily a direct relationship with one or more ASs. [FI] indeed we co= uld remove that limitation, to have a more general definition=

Using the ISO style for definitions, I propose:

Authorization Server (AS): server that= grants rights and/or attributes to a particular end-user and that provides= them to a client in the form of an access token

= Since this definition is using= the words "rights" and "= ;attributes", these two terms need to be defined as well.

<= p style=3D"margin-right:0in;margin-bottom:0in;margin-left:0in">right: ability for an end-user to perform= a given operation on an object under the control of a RS<= /u>

attribute: property related to an = end-user

=C2=A0

[FI] I like your proposal in general. There migh= t be some discussions on the details. I don't think it makes sense to g= rant "attributes".=C2=A0=C2=A0=C2=A0

Some explan= ations: a "right" is able to support a capability scheme. An &quo= t;attribute" is able to support an ACL scheme.

These two schemes are able to support &= quot;discretionary access control" where the end-user has a "need= -to-know".

= However, some attributes are also able to support what=C2=A0 was called in = the past "mandatory access control"; for example, <= u>

<= span style=3D"font-family:Arial,sans-serif">if the end-user is cleared to &= quot;top-secret / marketing strategy".



Interact S= erver (IS) - this is a new proposed term

Manages the front-end interaction with the RO, in order to gather = its consent. Depending on the deployment model and the privacy requirements= ,
the IS may be a component of the AS, or may be distinct and managed b= y another party.

Example : an IS usually involves a web interface accessed by RO throu= gh a web browser.

Note : an IS is not always required, especially if the access is gr= anted through automated policies.

Using the ISO styl= e for definitions, I propose:

=C2=A0

= Interaction Server (IS)

component from the AS or server inte= rfacing with an AS that manages the interactions with a RO, in order to gat= her its authorization

Note : since the RO is an optional= component, the IS is also an optional component.

=

=C2=A0

[FI] i= ndeed IS is optional. note for myself when looking at RO : why is RO option= al ?=C2=A0=C2=A0

=

Client

Requests privileges from t= he AS, and uses access tokens at the RS. This specification differentiates = between a specific instance (the client instance, identified by its unique = public key)
and the software running the instance (the client software)= . . For some kinds of client software, there could be many instances of a s= ingle piece of client software.
The AS determines which policies apply t= o a given client instance, including what it can request and on whose behal= f.

Some comments: The above text is stating: "(the client instance, identified by its unique pub= lic key)".
A client instance may use a public key, but that key is= not necessarily unique, in particular when there are multiple ASs.<= /span>

[FI] yes, although when possible I would still consi= der a better practice to expose a key to a specific AS and not to the entir= e set of available ASs.=C2=A0

Example : a client can be a mobile application or a web application (the= client software) that requires authorizations from the RO to retrieve cont= ent from various protected APIs. The client instance may for instance refer= to a specific version of that client software.

See on-going discussion : https://github= .com/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance).

Using the ISO style for definitio= ns, I propose:

Client: application used by an end-user to interact with an A= S or a RS

Note: a client can be a mobile application or a web application [FI] for me those= are just examples, because there could me more (ex IoT device)

[FI] you remove the entire discussion on client ins= tance / client software, is that on purpose because you think it's not = useful/right, or is it because of something else? (maybe add your comment o= f the related issue)=C2=A0 =C2=A0

Resource Server (RS)<= u>

Accepts valid access = tokens from the client issued by the AS and serves protected resources on b= ehalf of the RO. There could be multiple RSs protected by the AS that the c= lient may call.

Example : a RS is often composed of protected APIs that can be consu= med by authorized client software.=C2=A0

One c= omment: a RO is not necessarily involved. [FI] a bit hard to imagine, there's some k= ind of owner. Could you be more explicit?

Using the ISO s= tyle for definitions, I propose:

Resource Server (RS): server that accepts valid access tok= ens from clients issued by one or more ASs which are used to grant or deny = some requested operations

Note: a RS is often composed of protected APIs= that can be consumed by clients.



Resourc= e Owner (RO)

Authorizes the request to access a protected resource from the RS to t= he client. The RO may decide to remove its consent at any time.

Note : the RO may be= a physical person or may represent an organization.

=C2=A0

<= p style=3D"margin-right:0in;margin-bottom:0in;margin-left:0in">Two comments: In orde= r to avoid confusion with the end-user consent, the word " authorizati= on" is being used instead of "consent". [FI] ok=C2=A0<= /u>

It should be s= aid that the RO is an optional component.=C2=A0[FI] why?<= /span> Using the ISO style for definitions, I propose:=

Resource Owner (RO): physical person = acting on its own or representing an organization that authorizes to client= s operations on protected resources from a RS

Note: The RO is an optiona= l component that may interact either with one RS or with one or more ASs ,e= .g. using an IS.

=E2=80=93 this was previously Requesting P= arty RQ

=

A physical person that operates a= nd interacts with the client software.

Note : the end-user may or may not be the sa= me entity as the RO.

The Note is slightly incorrect. the physical person may or may not be the same entity as the RO. [FI] I didn't understand your comment

Using the ISO style for definitions, I propose:<= u>

End-user :=C2=A0 physical person that operates and interacts with the = client software

Note : that physical person may or may no= t be the same entity as the RO.

=C2=A0

Access Token<= /u>

A set of privilege= s delegated to the client instance for a specific end-user. An access token= is created by the AS, consumed and verified by the RS, and issued to and c= arried by the client's end-user on behalf of the RO. The contents and f= ormat of the access token are opaque to the client.

Example : JWT is a commonly used= format.

Note 1 : an access token generally has a limited duration, after which it = may be refreshed at a regular interval.

Note 2 : an access token may be revoked at a= ny time by the RO.

Note 3 : = an access token may act as a capability or require an additional authentica= tion by binding to a key

=

A fundamental point: the third sentence f= rom the definition states: "The co= ntents and format of the access token are opaque to the client".

[FI] I'll check your other thread dedicated to = that issue=C2=A0

=

See my other email sent today about "= ;RS-Token Introspection or RC-Token Introspection" where I conclude:

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 For end-users caring about their privacy (or for systems willi= ng to protect the user's privacy), access tokens should not be consider= ed
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 to be opaque to RCs nor to RSs and ASs should not support T= oken Introspection, whether it is RS-Token Introspection or RC-Token Intros= pection.

The example and the other Notes above should be removed. If needed th= ey should be placed in the main body of the document.<= /p>

Using the ISO style for definitions, I propose:

Access Token : digitally signed data issued by an Aut= horization Server (AS) and consumed by a Resource Server (RS)
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that contains = rights and/or attributes granted to a p= articular end-user

=C2=A0

Grant

The process by whic= h the client requests and is given delegated access to the RS by the AS thr= ough the authority of the RO.

Us= ing the ISO style for definitions, I propose:

G= rant: permission given to end-user to use a subset of his rights and/or his= attributes at a specific time and for a specific duration



Key

A public cryptographic binding a request to the holder of a private = key. Access tokens and client instances can be associated with specific key= s at a point in time.

Note : a key can be rotated or revoked by its holder. The pro= tocol supports the update of the key information.

=

"key" is a general term that is well understood and that does= not need to be defined. [FI] I really wouldn't bet on that. We can reuse an existin= g definition but it is a central piece so we need to be explicit<= /u>

The &qu= ot;definitions" section is not intended to explain what can be done wi= th the term that is being defined. [FI] ok we can work on that
Until the= word "key" is qualified using one or more other terms, this defi= nition should be removed.



Resource

A protected API serv= ed by the RS and accessed by the client if and only if access has been gran= ted. Access to this resource is delegated by the RO as part of the grant pr= ocess.

The second sentence of the definition is= not in accordance with the ISO style or definitions and furthermore this s= econd sentence should be removed since a RO is an optional element.<= u>

=C2=A0<= /u>

Using the ISO style for definitions, I propose:

Resource: protected API serve= d by a RS and accessed by a client, if and only if access is granted by an = access token

=C2=A0

This definition exhibits seve= ral problems:

(1) The term "sub= ject" is not defined.

(2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

(3) The Note states : &quo= t;this information needs to be unique". Does it mean unique for the AS= ? globally unique ?

This definition should be revisited. = [FI] I agree = (I myself had many questions here)

Denis<= u>

=C2=A0

= =C2=A0



<= /p>

=C2=A0

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

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

--0000000000004eb9f105b656b7a3-- From nobody Sun Dec 13 10:04:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7FC3A08AF for ; Sun, 13 Dec 2020 10:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=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 Ob1HwU__V9ki for ; Sun, 13 Dec 2020 10:04:07 -0800 (PST) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 299D73A08B0 for ; Sun, 13 Dec 2020 10:04:07 -0800 (PST) Received: by mail-oo1-xc2a.google.com with SMTP id i18so3435667ooh.5 for ; Sun, 13 Dec 2020 10:04:07 -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=d2sXQyalr7rezSsZ7XaiZMvuG0J50JLN6r1QWSGkIFQ=; b=NNQPi15rUs6nVCSBeW1AnmIzT9/4kK7ToMF4EnO+3cz9tTiHcwsgd0HGJLHRzLDwJk /TpCRh3WKYGvgy5on5XeBZoF+NBg1ChujLBIMz6K79m+YJ7cCyqiFVkm1D2/e26/ZtmE LCbAD6Bqzbx/oqkOm+0q4lbvj0gWTNQ5/3yFhpaQ9zdLkgtsSdn4jKxDrh/PCKwoWIWN WeRoIGyHA3I4v405dy/oB+d/T8ixF5+2pmrYkrCppxSqW40wVj4YYxoDuk6b2EYQ4eXS 4VlzIZSTnCrw1WwOQP8Q3I/tXlQOA/1rWFYwtTIiIMKuPeutbXr7Eie2nkWBB8RlfFW+ 7nUw== 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=d2sXQyalr7rezSsZ7XaiZMvuG0J50JLN6r1QWSGkIFQ=; b=XpDqTT5WosJ1oynuNJzuYC+OH0zNus1ptFzt8FCOp4WQ9NfDp4oXHVSqfYqjV0BdLu 4e4SUiQR3rs675525ebX600oXxwO8/DjGnCUhDJkwkYzpbCkdFfu3cotQrz/Jgfis2BR TTDXNkBaZB7kaT+6lwPM3kR/iMrQXUHABA8ICTNX0cEVLuZ/5canpvcU0Ir6eKGVynjp /1LGRWwlh9HkjtuXWpqYz/FI7O/RBKd0A+9OAKESsfO6u/lkK3dVrMnFiMDv5omlKOVE ph96ou9eT0qfloZlWNrJbp0zxXst5U9BE2MsW665EZAv/WvrcVP3zLYj6/OGJwXCadbP VcWw== X-Gm-Message-State: AOAM531ODBZKo6NOJR6MyPtmDIELK6IgsBjMdirdxIoJrmJCP5qRq5kU uDiZzt3jgBdSULNXhGHikCGLWcNMYJFl8575JzaxVMx0IXulAA== X-Google-Smtp-Source: ABdhPJzgsU15Of3BifyNGpS3MeRXjh4MnJ8DffTVHaAd9tXMISkQgsQoaOiWHZLejnxcF5us/YBpPG+3hELrOX86480= X-Received: by 2002:a4a:a3cb:: with SMTP id t11mr16761976ool.30.1607882645842; Sun, 13 Dec 2020 10:04:05 -0800 (PST) MIME-Version: 1.0 From: Tom Jones Date: Sun, 13 Dec 2020 10:03:54 -0800 Message-ID: To: txauth gnap Content-Type: multipart/alternative; boundary="000000000000f22d8505b65c59c8" Archived-At: Subject: [GNAP] client definition 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, 13 Dec 2020 18:04:08 -0000 --000000000000f22d8505b65c59c8 Content-Type: text/plain; charset="UTF-8" This definition is highly use case specific. It leaves out the possibility of (eg) a self-issued identifier where the RP displays a request to the user on a web page, the user clicks the button and the result is that a wallet on the user's device acting as the AS sends an access token to the RP (which is typically the client in an OAUTH sense.) The underlined part is often incorrect. Client - Definition: application *used by an end-user* to interact with an AS or a RS suggestion: Client, an application that desires to get access privileges from a user to resources on an RS, possibly by way of an AS. Peace ..tom --000000000000f22d8505b65c59c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This definition is highly use case specific. It leaves out= the possibility of (eg) a self-issued identifier where the RP displays a r= equest to the user on a web page, the user clicks the button and the result= is that a wallet on the user's device acting as the AS sends an access= token to the RP (which is typically the client in an OAUTH sense.) The und= erlined part is often incorrect.

Client

  • Definition: application used by an end-u= ser to interact with an AS or a RS
suggesti= on: Client, an application that desires to get access privileges from a use= r to resources on an RS, possibly by way of an AS.
=
Peace .= .tom
--000000000000f22d8505b65c59c8-- From nobody Sun Dec 13 10:07:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED023A08C5 for ; Sun, 13 Dec 2020 10:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 AIN4KKbQl0Ua for ; Sun, 13 Dec 2020 10:07:06 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 150D13A08C3 for ; Sun, 13 Dec 2020 10:07:05 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id q25so13508962otn.10 for ; Sun, 13 Dec 2020 10:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gEaURIO1dAL7bfUnQQreteCE8YFlIfKjsD5sUeUOwVk=; b=Ack1946K2aJYMueAhZV67nvj5+PqEBkzN75/EkbqY/EMStu2A8x7B0V1119nDjHJ5a WfV/wGNc7b2IGTTj+yIveeOqOWf+L5zRcv1KWMj/qiMRTkAG8PqlSgTnDhVT9WPaHbmg IntK/gJnrxVNijP5GxdukN2QdwL7SMU5AMp0P+sGmxcWGwxcz0nhTQsppcKbhnjMwcwM 2MpeyXjLgm2PTq0EGa+vzUvhBhx1Qe+deFOqBJFpuJDNMMOJkDkg10ps80kRfPg96gvR OrcC1dAAXDP9uCWpDqveFgLsvkzGRBM6dBc61WLV/pi1iLTzueGBomMiPjumugbeu8kU vzXQ== 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=gEaURIO1dAL7bfUnQQreteCE8YFlIfKjsD5sUeUOwVk=; b=J+DogA++L8pGvvSGFOdxpOaHf9qOR7dC+vIRUWto+OQjgdLQxCxXruJlsc0VDupNSt MPhvz8t03PJuqvVW1PBEEwjAqA3YzrqIOZYt/uuUUTW4KNq4g2CiQtvPoA3XEXy7dG3S M5CoA3LKGVwtejFjTJ7WUHZIB6n2sjtyAMm/IFAcGiU0geJnPxJcyKN1dZQdT2C6nNbS 9RP3Ub09gwzyHiJijM2lJXTasFK77NE7Y6NZen61zKhnSDswpltpEgmNIMt7LYszmffC 6PHnilfghnHag3NMJkWeox1DFGYszc3YATPtC3TV0Jt5PF3XeAUVfmxO3PGOlaeRRC+0 nr0w== X-Gm-Message-State: AOAM533XYJ1rqq576hX/I+UjE6yUjwJUb482FMcDOCKv0LomhEMZSR2D u9E4w3HiHqTkums4INS3Nk0WiOV6uanX/08GwHpOUghFkSM= X-Google-Smtp-Source: ABdhPJy2vkZaC6q6bqsAdmig4kVoqTcOTZ76nS+t2KSMBSMDpnkbFozlkQbsixIc5ZQvNkf5vH+LCdbcMiSecAmeCAI= X-Received: by 2002:a9d:ece:: with SMTP id 72mr16431346otj.358.1607882824483; Sun, 13 Dec 2020 10:07:04 -0800 (PST) MIME-Version: 1.0 From: Tom Jones Date: Sun, 13 Dec 2020 10:06:53 -0800 Message-ID: To: txauth gnap Content-Type: multipart/alternative; boundary="00000000000098074d05b65c64ff" Archived-At: Subject: [GNAP] physical person 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, 13 Dec 2020 18:07:07 -0000 --00000000000098074d05b65c64ff Content-Type: text/plain; charset="UTF-8" I dislike this. A robot can be a physical person. What's wrong with natural person that others use? Peace ..tom --00000000000098074d05b65c64ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I dislike this. A robot can = be a physical person. What's wrong with natural person that others use?=
Peace ..tom
--00000000000098074d05b65c64ff-- From nobody Sun Dec 13 10:09:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD37A3A08D3 for ; Sun, 13 Dec 2020 10:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=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 Dz7HLK3MhEFZ for ; Sun, 13 Dec 2020 10:08:58 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 B5DDB3A08CA for ; Sun, 13 Dec 2020 10:08:58 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id p126so16594293oif.7 for ; Sun, 13 Dec 2020 10:08:58 -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=Lpa1cvyP83wMUb/l/xy0nblxWU9sYavpl+SaGH7xcy4=; b=nCyCb9uenwn9jRf/Ly/2Z9PxsTm+L65egpvlQgqyDw3bbLsPLN4m5+o0TU/CriI/wd iByNTaGtLxBdBb8UVa5iiKu9gCwmneA5z1M3v9/F7n4At+bZHhs3KN3O53BPuLaBaJ3O AXFZ1wECujvopODfQitRfob17KZQQxe6Y6Ud8y14y/TehhtUptSVsU9OiBGaNS8+1Iuz 9az0MByy3ChfCiKWCOjeRCuRdDLenkMhrDDmF8z9wqaHjLAVa14AlR/ob+bdDHRRcoGQ 4Radpudn//Bex1qjXIYslbUOSPslc8FowTOXrjw7BaNT60NL1QPMRBZ42szMCMoqg/CS K+kA== 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=Lpa1cvyP83wMUb/l/xy0nblxWU9sYavpl+SaGH7xcy4=; b=rXFAujCKxFruktlAsujIMZY3EatQCDdPn3nbqv/ksWmr3e5Mx7CreP8ncpqquxXHew LwIhFvL9tKbqQs8f/SWe2Bo2iMOPEqS/E/bJpUBW6T2KkP2Ehz2XgCy6VnRBJOwul2JL HlCTzwKR6vcNsH6jfjYaZc5l7B/dCFZAwTAscO2JzB2WaYMfg+V+X8mo/4wghPwwWMzn sPyvRNvKTbhpluZncqMhPiUX5AOBfUbB71mYPVDtkLAJLkjOrTeTWfiG4G7tczkrhzQw Os/C8bRMf8945urgvFdtR/IfaQH7ZusBzZWhCzv5sx2gJ7yjbtIdCJqyrD6Hxne2AR8G Ftag== X-Gm-Message-State: AOAM531M9vBq4y/oeQUe3sGuzFaZ71ntaZhlI5Mk8hshpWLVs33qzoJ3 NQaw8gsMTn8r71tezdZnVuPTP0tYngOM9UnV8F89ISi/jwUv7g== X-Google-Smtp-Source: ABdhPJybCnCAtFeHdijtFqTyNYdZRyJZ5tTNIJ2//JPLaghrseMYBEYVGV+9j/xACDuirkq8e++hy+l2QNwc0vCFKrM= X-Received: by 2002:aca:470e:: with SMTP id u14mr15519860oia.172.1607882935265; Sun, 13 Dec 2020 10:08:55 -0800 (PST) MIME-Version: 1.0 From: Tom Jones Date: Sun, 13 Dec 2020 10:08:43 -0800 Message-ID: To: txauth gnap Content-Type: multipart/alternative; boundary="000000000000326fd405b65c6bb7" Archived-At: Subject: [GNAP] grant - noun 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, 13 Dec 2020 18:09:00 -0000 --000000000000326fd405b65c6bb7 Content-Type: text/plain; charset="UTF-8" this is not an act but an artifact of an act Peace ..tom --000000000000326fd405b65c6bb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --B_3690738739_988194379-- From nobody Sun Dec 13 11:21:18 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF4F3A0045 for ; Sun, 13 Dec 2020 11:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 riALtAha4KuK for ; Sun, 13 Dec 2020 11:21:12 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 3BF3D3A003E for ; Sun, 13 Dec 2020 11:21:11 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id m23so26672ioy.2 for ; Sun, 13 Dec 2020 11:21:11 -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=SySjjEYfi/b40IHSamsh5dSmvi9lHmi+88WyO2mt77A=; b=Z1VycQ2DFidkSqCSIsE/FHxzH9vX8UM1AAMASypntG9OKbWzSxU0rQVXQYMSTL9STP 9/AQ4SL9ejtxyCUV0TvKDvc9u8kcI5Z2CoteFMih0XPn1sp20e717VaorYcCbf2OAajV Syfl7M+YxkkmqSfuOzBGZesRAePwNttkt83KzuEnM9anezo8l7vpXLuH5R/GpOYlYP8U nwiZqNB4WxKx6uV8VnjIw2fgyqdAsjQ3LqgE2ph+3LPhEBTdfNpotJ30C8nO7iwhNn0l d6/sO8yzGTPVl72kAlNw0SLjHiZrhKzlKRNQ5aVcqiOtItcnR5ayoHXkj5P5l5rd6jsM kEew== 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=SySjjEYfi/b40IHSamsh5dSmvi9lHmi+88WyO2mt77A=; b=UIfRJwFWISRvBuBX9f5FrdDDo1CccdtMLzj5l3+pJHwufN6Xgi+GF+FQ9500w6aTZY SORXnN8Gu0piEsp+XcGh+Xl7n7WoMEOJkQJ7POfT6FFeC6pQXs2BfqiE4PAK9/saX9hS 2sGLtk9Yy9iu9MSsg9HegMW/D2iXEa3K9cCzPu4c9Z1lkeLwRMAtmveJblGz74atnGxB qhaUS0Nmxypbc+WFMUJuMygPPsdkypV1Wqb+/2k2R2CTG5addu5EcByhXT76QueSf6ij FZScIhbfWZokt0te/+JuzS/D/RNaQcTIXwBcthjE5Cw+4RkP+IdVMKEgHq57189rag7/ 4jPw== X-Gm-Message-State: AOAM532pwsDw0yQfFno2ceNxY+ESc6G9uWI/9eYu7PwRJSqVEhk7N4Hg vl7SXn7IzuvcikpA/2+UFOWuLh1VRp1bzPlupSU= X-Google-Smtp-Source: ABdhPJwx2js03OWdajllU9ZF6DVG9u9e5XQLoT4li9k7EEc/9far24Mh3GCmdOoC/AJS2iycQ1iTaLYQ/k2QdJHXt2g= X-Received: by 2002:a5e:a916:: with SMTP id c22mr27190404iod.144.1607887271123; Sun, 13 Dec 2020 11:21:11 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> <13422918-A279-45FD-97B7-E02D74534960@gmail.com> In-Reply-To: <13422918-A279-45FD-97B7-E02D74534960@gmail.com> From: Fabien Imbault Date: Sun, 13 Dec 2020 20:20:59 +0100 Message-ID: To: Yaron Sheffer Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000a261fc05b65d6d92" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 19:21:17 -0000 --000000000000a261fc05b65d6d92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Stylistic comments are very important too. And at some point we'll need a review from native english speakers in the group (I'm sure Justin and Aaron will be of great help here). Just wondering: what do you mean by "typically"? (ideally I'd rather have a definition which is not dependent on use case). As soon as we land on something, I'll update the wiki. Fabien On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer wrote= : > It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9C= server that > denies operations=E2=80=9D) a bit funny. How about: > > > Resource Server (RS) > > - Definition: server that provides operations on protected resources; > such operations typically require that the client provide valid access > tokens issued by an AS > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Sunday, December 13, 2020 at 13:20 > *To: *Yaron Sheffer > *Cc: *Denis , GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hello everyone, > > > > We're at the end of the 2 week period, and so I integrated the various > feedbacks : > > > > a) from Yaron's feedback, removed new term "IS" and update issue > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle > the proposal here > > b) integrated Tom's feedback regarding the RO (and moved to access token= ) > > c) definitions follow an ISO style as suggested by Denis, which we took a= s > a starting point (but I made the modifications I felt were necessary) > > > > I modified the definitions, notes and examples as a consequence. You'll > also find a summary of discussions for each term, so that we can keep tra= ck > of them too. > > > > My biggest question is : what should we use as our main vocabulary betwee= n > privilege/rights/attribute? I tried to clarify, please let me know what y= ou > think. The general idea is that we grant privileges that are delivered > under the form of access tokens (which contain rights and/or attributes). > > Regarding whether access tokens should be opaque or not, I suggest to > remove that from the definition and handle that in issue > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 > > > > All has been consolidated on the wiki too > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so > that we have a clearer view of where we stand. > > > > Please comment further on the list if you have comments, I'll update if > necessary (and refer to the mailing list url in the comment of the wiki > update, from now on). Then editors will review the proposal. > > Here is a copy of > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology#lates= t-discussion-update > . > > > Latest discussion update > > Here we consolidate the latest proposal(s) from the group. We also includ= e > the discussion items (individual feedbacks). > Authorization Server (AS) > > - Definition: server that grants privileges to a particular end-user > and that provides them to a client in the form of an access token > > Feedbacks / discussion / questions : > > - Suggested "privilege" definition (that we would probably add as an > additional sub-entry): "A privilege is the right to perform an operati= on > (or action) on a Resource." See also other def > > - Note that we don't include claims in the definition (cf OIDC/SSI > integration), but since we talk about a "particular end-user" it is as= sumed > somehow > - Denis suggested we used "rights and attributes" instead of > privileges. [FI] However i don't think one can really speak about gran= ting > attributes, except indirectly (ABAC). See access token for more on tha= t, > where we can be more specific. > - Do we allow cases such as distributing the AS on a mobile? (in this > case we're at the limit of what we call a server) > > Client > > - Definition: application used by an end-user to interact with an AS > or a RS > - Note: this specification differentiates between a specific instance > (the client instance, identified by its public key) and the software > running the instance (the client software). For some kinds of client > software, there could be many instances of a single piece of client > software. > - Example: a client can be a mobile application, a web application, > etc. > > Feedbacks / discussion : > > - Replaces previously proposed RC, we wouldn't provide a short name. > - Keep OAuth2 term, but we clarify it > - Further discussion on Client instance > > > Resource Server (RS) > > - Definition: server that denies operations on protected resources, > unless the client provides valid access tokens issued by an AS > > Feedbacks / discussion : > > - Denis suggests to make explicit that we could have several ASs - > "issued by one or more ASs" (also we'd need a convention on how to den= ote > plural, e.g. ASs). Not exactly sure right now of the multiple issuance > would work, so needs to be clarified. Also not sure if that's even > necessary (do we lack in generality if we keep the singular?) > > Resource Owner (RO) > > - Definition: physical person acting on its own or representing an > organization, that may grant privileges on resources he has authority = upon > - Note: the act of granting privileges may be manual (i.e. through an > interaction) or automatic (i.e. through predefined rules). > > Feedbacks / discussion > > - As some point we suggested "The RO may decide to remove its consent > at any time." Tom provided useful feedback > on > that. Moved to access token where it fits more naturally. > > End-user > > - Definition: physical person that operates with the client software > - Note: that physical person may or may not be the same entity as the > RO > > Access token > > - Definition: digitally signed data that contains specific rights > and/or attributes > - Note 1: the access token can be issued to an end-user (usually > requiring his authentication) and subsequently refreshed. The AS usual= ly > provides a method for the RO to revoke the privileges at any point in = time. > - Note 2: an access token may act as a capability (i.e. bearer token) > or require an additional authentication by binding to a key (i.e. boun= d > token) > > Feedbacks / discussion > > - Would require the subdefinitions right: ability for an end-user to > perform a given operation (or action) on a resource (or object) under = the > control of a RS / attribute: property related to an end-user. > - Note 2 is here in relationship with PR 129 > > > Grant > > - Definition (verb): to permit, as a privilege given to an end-user to > exercise some rights and/or assert attributes during a specific durati= on > - Definition (noun): the act of granting > > Key > > - Definition: public cryptographic binding a request to the holder of > a private key, used by the protocol entities (AS, RS, client instance, > bound token, etc.) to identify themselves. > - Note: a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > Feedbacks / discussion > > - Denis thinks the term "key" is well understood and doesn't need to > be defined. Yet, I tend to believe we'd gain to keep it. First the gen= eric > term "key" may be many things : symmetric/asymmetric, public/private, = etc. > It's also useful to explain its use in the protocol > > Resource > > - Definition: protected API served by a RS and accessed by a client, > if and only if a valid access token is provided > > > > On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault > wrote: > > Hi Yaron, > > > > Yes I highlighted that this was a new term. We can deal with it as a > separate issue indeed. > > > > Best > > Fabien > > > > On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer > wrote: > > Hi Fabien, > > > > Yes, we definitely need to reach closure on terminology, thank you for > driving this discussion! > > > > One process comment: unless I=E2=80=99m missing something, the Interact (= or > Interaction) Server is not mentioned in the current draft. I suggest we d= o > not introduce new functional components or new behaviors as part of the > terminology discussion. Specifically, if the IS is useful, let=E2=80=99s = reach > consensus on that separately. Then we can add it into the Terminology > section. > > > > Thanks, > > Yaron > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Friday, December 11, 2020 at 14:31 > *To: *Denis > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hi Denis, > > > > Thanks for your detailed feedback. My comments are embedded into your > message. Again those comments are my own, and we'll need to converge to > some consensus beyond what I say here. My main open question is really > about the RO being optional. Could you explain? > > > > Fabien > > > > On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: > > This is a global response to the definitions proposal. > > > TerminologyI propose to adopt the way ISO defines how to write the > definitions.It is a *single sentence* that may be substituted to the > wording being defined in the context of a sentence that uses that > definition. > Since this single sentence can be substituted to the wording, there is no= t > point at the end of that sentence. The sentence does not > have a "a" or "the" in front of it. > > > > [FI] In the first version, I was mostly trying to not get too far away > from the current text. But yes that's a good idea, it gives a more formal > rule, which has been proven to work. > > > > If more information is useful to understand the wording, it is placed in > one or more notes afterwards. > > > > Note: The ISO rules for drafting definitions are in the ISO/IEC > Directives, Part 2 (edition 2018): > > 16.5.6 Definitions > > The definition shall be written in such a form that it can replace the > term in its context. It shall not start with an article (=E2=80=9Cthe=E2= =80=9D, =E2=80=9Ca=E2=80=9D) nor > end with a full stop. > A definition shall not take the form of, or contain, a requirement. > > Only one definition per terminological entry is allowed. If a term is use= d > to define more than one concept, a separate terminological entry shall be > created > for each concept and the domain shall be included in angle brackets befor= e > the definition. > > Circular definitions, which repeat the term being defined, are not allowe= d. > > Comments are inserted between the lines. > > > > Hello everyone, > > > > As an editor : a quick reminder that terminology issues will be discussed > in the coming weeks, and we're expecting your inputs right now (according > to the process previously sent on the mailing list). > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 > > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > > > > The rest of this message is a proposal written in my own name, and doesn'= t > involve discussions with the editors/chairs who might have different > opinions. > Authorization Server (AS) > > Manages the granting of privileges to a third-party client instance. If > the RO consents to at least a part of what is requested, the AS issues an > access token to the client. > > *My questions: * > > *- was else do we issue? (e.g. id claims, payment info, etc.) We could > have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D = is not clear. I > removed that for now.* > > *- there might potentially be several AS, currently we don=E2=80=99t refl= ect that > anywhere. If would leave that as an open item, depending on what we end u= p > doing in the spec* > > I am not in favour of this definition: A RO as defined later: "authorizes > the request to access a protected resource from the RS to the client". > This does not mean in any way that a RO has necessarily a direct > relationship with one or more ASs. [FI] indeed we could remove that > limitation, to have a more general definition > Using the ISO style for definitions, I propose: > > Authorization Server (AS): server that grants rights and/or attributes to > a particular end-user and that provides them to a client in the form of a= n > access token > > Since this definition is using the words "rights" and "attributes", these > two terms need to be defined as well. > > right: ability for an end-user to perform a given operation on an object > under the control of a RS > > attribute: property related to an end-user > > > > [FI] I like your proposal in general. There might be some discussions on > the details. I don't think it makes sense to grant "attributes". > > Some explanations: a "right" is able to support a capability scheme. An > "attribute" is able to support an ACL scheme. > > These two schemes are able to support "discretionary access control" wher= e > the end-user has a "need-to-know". > > However, some attributes are also able to support what was called in the > past "mandatory access control"; for example, > > if the end-user is cleared to "top-secret / marketing strategy". > > > > Interact Server (IS) - this is a new proposed term > > Manages the front-end interaction with the RO, in order to gather its > consent. Depending on the deployment model and the privacy requirements, > the IS may be a component of the AS, or may be distinct and managed by > another party. > > Example : an IS usually involves a web interface accessed by RO through a > web browser. > > Note : an IS is not always required, especially if the access is granted > through automated policies. > > Using the ISO style for definitions, I propose: > > > > Interact*ion* Server (IS) > > component from the AS or server interfacing with an AS that manages the > interactions with a RO, in order to gather its authorizationNote : since > the RO is an optional component, the IS is also an optional component. > > > > [FI] indeed IS is optional. note for myself when looking at RO : why is R= O > optional ? > > Client Requests privileges from the AS, and uses access tokens at the RS. > This specification differentiates between a specific instance (the client > instance, identified by its unique public key) > and the software running the instance (the client software). . For some > kinds of client software, there could be many instances of a single piece > of client software. > The AS determines which policies apply to a given client instance, > including what it can request and on whose behalf. > > Some comments: The above text is stating: "(the client instance, > identified by its unique public key)". > A client instance may use a public key, but that key is not necessarily > unique, in particular when there are multiple ASs. > > [FI] yes, although when possible I would still consider a better practice > to expose a key to a specific AS and not to the entire set of available > ASs. > > Example : a client can be a mobile application or a web application (the > client software) that requires authorizations from the RO to retrieve > content from various protected APIs. The client instance may for instance > refer to a specific version of that client software. > > *See on-going discussion : > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 > (client > instance). * > > Using the ISO style for definitions, I propose: > > Client: application used by an end-user to interact with an AS or a RS > > Note: a client can be a mobile application or a web application [FI] for > me those are just examples, because there could me more (ex IoT device) > > [FI] you remove the entire discussion on client instance / client > software, is that on purpose because you think it's not useful/right, or = is > it because of something else? (maybe add your comment of the related > issue) > > Resource Server (RS) > > Accepts valid access tokens from the client issued by the AS and serves > protected resources on behalf of the RO. There could be multiple RSs > protected by the AS that the client may call. > > Example : a RS is often composed of protected APIs that can be consumed b= y > authorized client software. > > One comment: a RO is not necessarily involved. [FI] a bit hard to > imagine, there's some kind of owner. Could you be more explicit? > Using the ISO style for definitions, I propose: > > Resource Server (RS): server that accepts valid access tokens from client= s > issued by one or more ASs which are used to grant or deny some requested > operations > > Note: a RS is often composed of protected APIs that can be consumed by > clients. > > > > Resource Owner (RO) > > Authorizes the request to access a protected resource from the RS to the > client. The RO may decide to remove its consent at any time. > > Note : the RO may be a physical person or may represent an organization. > > > > Two comments: In order to avoid confusion with the end-user consent, the > word " authorization" is being used instead of "consent". [FI] ok > > It should be said that the RO is an optional component. [FI] why? Using > the ISO style for definitions, I propose: > > Resource Owner (RO): physical person acting on its own or representing an > organization that authorizes to clients operations on protected resources > from a RS > > Note: The RO is an optional component that may interact either with one R= S > or with one or more ASs ,e.g. using an IS. > > End-user =E2=80=93 this was previously Requesting Party RQ > > A physical person that operates and interacts with the client software. > > Note : the end-user may or may not be the same entity as the RO. > > The Note is slightly incorrect. the *physical person* may or may not be > the same entity as the RO. [FI] I didn't understand your comment > Using the ISO style for definitions, I propose: > > End-user : physical person that operates and interacts with the client > software > > Note : that physical person may or may not be the same entity as the RO. > > > > Access Token > > A set of privileges delegated to the client instance for a specific > end-user. An access token is created by the AS, consumed and verified by > the RS, and issued to and carried by the client's end-user on behalf of t= he > RO. The contents and format of the access token are opaque to the client. > > Example : JWT is a commonly used format. > > Note 1 : an access token generally has a limited duration, after which it > may be refreshed at a regular interval. > > Note 2 : an access token may be revoked at any time by the RO. > > Note 3 : an access token may act as a capability or require an additional > authentication by binding to a key > > A fundamental point: the third sentence from the definition states: "The > contents and format of the access token are opaque to the client". > > [FI] I'll check your other thread dedicated to that issue > > See my other email sent today about "RS-Token Introspection or RC-Token > Introspection" where I conclude: > > For end-users caring about their privacy (or for systems willing to > protect the user's privacy), access tokens should not be considered > to be opaque to RCs nor to RSs and ASs should not support Token > Introspection, whether it is RS-Token Introspection or RC-Token > Introspection. > > The example and the other Notes above should be removed. If needed they > should be placed in the main body of the document. > > Using the ISO style for definitions, I propose: > > Access Token : digitally signed data issued by an Authorization Server > (AS) and consumed by a Resource Server (RS) > that contains rights and/or attributes granted > to a particular end-user > > > > Grant > > The process by which the client requests and is given delegated access to > the RS by the AS through the authority of the RO. > > Using the ISO style for definitions, I propose: > > Grant: permission given to end-user to use a subset of his rights and/or > his attributes at a specific time and for a specific duration > > > > Key > > A public cryptographic binding a request to the holder of a private key. > Access tokens and client instances can be associated with specific keys a= t > a point in time. > > Note : a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > "key" is a general term that is well understood and that does not need to > be defined. [FI] I really wouldn't bet on that. We can reuse an existing > definition but it is a central piece so we need to be explicit > > The "definitions" section is not intended to explain what can be done wit= h > the term that is being defined. [FI] ok we can work on that > Until the word "key" is qualified using one or more other terms, this > definition should be removed. > > > > Resource > > A protected API served by the RS and accessed by the client if and only i= f > access has been granted. Access to this resource is delegated by the RO a= s > part of the grant process. > > The second sentence of the definition is not in accordance with the ISO > style or definitions and furthermore this second sentence should be remov= ed > since a RO is an optional element. > > > Using the ISO style for definitions, I propose: > > Resource: protected API served by a RS and accessed by a client, if and > only if access is granted by an access token > > Subject Information > > Information about a subject (usually a RO) that is returned directly to > the client from the AS. > > Note : this information needs to be unique. > > > > This definition exhibits several problems: > > (1) The term "subject" is not defined. > > (2) The information that is returned is for an end-user, i.e. not for "(u= sually > a RO)". > > (3) The Note states : "this information needs to be unique". Does it mean > unique for the AS ? globally unique ? > > This definition should be revisited. [FI] I agree (I myself had many > questions here) > > Denis > > > > *My questions : * > > *- probably we=E2=80=99d need to define subject* > > *Subject : > https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject= +Dictionary+Entry > * > > *- might be useful to clarify the relationship to what identity providers > do * > > > > > > 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 > > --000000000000a261fc05b65d6d92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,=C2=A0

Stylis= tic comments are very important too. And at some point we'll need a rev= iew from native english speakers in=C2=A0the group (I'm sure Justin and= Aaron will be of great=C2=A0help here).

Just wond= ering: what do you mean by "typically"? (ideally I'd rather h= ave a definition which is not dependent on use case).

<= div>As soon as we land on something, I'll update the wiki.
Fabien



On Sun, Dec 13, 2020= at 8:12 PM Yaron Sheffer <yaro= nf.ietf@gmail.com> wrote:
<= div>

It=E2=80=99s purely stylistic, but I find the de= finition of RS (=E2=80=9Cserver that denies operations=E2=80=9D) a bit funn= y. How about:

=C2=A0<= /p>

R= esource Server (RS)

    =
  • Definition: server that provides operations on protected resources; such o= perations typically require that the client provide valid access tokens iss= ued by an AS

Thanks,

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

=C2=A0

From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Sunday, Decemb= er 13, 2020 at 13:20
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc= : Denis <den= is.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
Subject: Re: [GN= AP] Terminology proposal

=C2=A0

Hello eve= ryone,=C2=A0

=C2=A0<= /u>

We're at the end of the 2 week= period, and so I integrated the various feedbacks :=C2=A0

=C2=A0

a) from Yaron's feedback, removed new term "IS&q= uot; and update issue=C2=A0https://github.com/ietf-wg-gnap= /gnap-core-protocol/issues/133 to handle the proposal here=C2=A0=

b) integrated Tom's feedba= ck regarding the RO (and moved=C2=A0 to access token)

c) definitions follow an ISO style as suggest= ed by Denis, which we took as a starting point (but I made the=C2=A0modific= ations I felt were necessary)

=C2=A0

I modified = the definitions, notes and examples as a consequence. You'll also find = a summary of discussions for each term, so that we can keep track of them t= oo.

=C2=A0=

My biggest question is : what should = we use as our main vocabulary between privilege/rights/attribute? I tried t= o clarify, please let me know what you think. The general idea is that we g= rant privileges that are delivered under the form of access tokens (which c= ontain rights and/or attributes).

Regarding whether access tokens should be opaque or not, I sugges= t to remove that from the definition and handle that in issue=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145

=C2=A0<= u>

Please comment further on the l= ist if you have comments,=C2=A0I'll update if necessary (and refer to t= he mailing list url in the comment of the wiki update, from now on). Then e= ditors will review the proposal.=C2=A0

=C2=A0

Latest disc= ussion update

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

Authorization Server (AS)

  • Definition: server that grants privileges to a particular end-user and = that provides them to a client in the form of an access token=

Feedbacks / discussion / = questions :

  • Suggested "pri= vilege" definition (that we would probably add as an additional sub-en= try): "A privilege is the right to perform an operation (or action) on= a Resource." See also=C2=A0other def
  • Note that w= e don't include claims in the definition (cf OIDC/SSI integration), but= since we talk about a "particular end-user" it is assumed someho= w
  • Denis suggested we used "ri= ghts and attributes" instead of privileges. [FI] However i don't t= hink one can really speak about granting attributes, except indirectly (ABA= C). See access token for more on that, where we can be more specific.
  • Do we allow cases such as distributing = the AS on a mobile? (in this case we're at the limit of what we call a = server)

Client

  • Definition: application used by an end-user= to interact with an AS or a RS
  • No= te: this specification differentiates between a specific instance (the clie= nt instance, identified by its public key) and the software running the ins= tance (the client software). For some kinds of client software, there could= be many instances of a single piece of client software.
  • Example: a client can be a mobile application, a web= application, etc.

Feedbacks / discussion :

  • Replaces previously proposed RC, we wouldn't provide a short name.
  • Keep OAuth2 term, but we clarify it=
  • Further discussion on=C2=A0Client instance

  • Definiti= on: server that denies operations on protected resources, unless the client= provides valid access tokens issued by an AS

    • Feedbacks / discussion :

    • Denis suggests to make explicit that we could h= ave several ASs - "issued by one or more ASs" (also we'd need= a convention on how to denote plural, e.g. ASs). Not exactly sure right no= w of the multiple issuance would work, so needs to be clarified. Also not s= ure if that's even necessary (do we lack in generality if we keep the s= ingular?)

    Resource Owner (R= O)

    • Definition: physical person = acting on its own or representing an organization, that may grant privilege= s on resources he has authority upon
    • Note: the act of granting privileges may be manual (i.e. through an inte= raction) or automatic (i.e. through predefined rules).=

    Feedbacks / discussion=

    • As some point we suggested "The RO = may decide to remove its consent at any time." Tom provided=C2=A0useful feedback=C2=A0on that. Moved to access t= oken where it fits more naturally.

    End-user

    • Definition:= physical person that operates with the client software
    • Note: that physical person may or may not be the same= entity as the RO

    Access to= ken

    • Definition: digitally signe= d data that contains specific rights and/or attributes=
    • Note 1: the access token can be issued to an end-user = (usually requiring his authentication) and subsequently refreshed. The AS u= sually provides a method for the RO to revoke the privileges at any point i= n time.
    • Note 2: an access token ma= y act as a capability (i.e. bearer token) or require an additional authenti= cation by binding to a key (i.e. bound token)

      • Feedbacks / discussion

      • Would require the subdefinitions right: ability f= or an end-user to perform a given operation (or action) on a resource (or o= bject) under the control of a RS / attribute: property related to an end-us= er.
      • Note 2 is here in relationship= with=C2=A0PR 129

      Grant

      • Definition (ver= b): to permit, as a privilege given to an end-user to exercise some rights = and/or assert attributes during a specific duration
      • Definition (noun): the act of granting

      Key

      • Definition: public cryptographic binding a request to the holder of a pr= ivate key, used by the protocol entities (AS, RS, client instance, bound to= ken, etc.) to identify themselves.
      • Note: a key can be rotated or revoked by its holder. The protocol supports= the update of the key information.

      Feedbacks / discussion

    • Denis thinks the term "key" is well understood an= d doesn't need to be defined. Yet, I tend to believe we'd gain to k= eep it. First the generic term "key" may be many things : symmetr= ic/asymmetric, public/private, etc. It's also useful to explain its use= in the protocol

    Resource

    • Definition: protected API served= by a RS and accessed by a client, if and only if a valid access token is p= rovided

    =C2=A0

    On Fri, Dec 11, 2020= at 6:05 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    =

    Hi Yaron,=C2=A0=

    =C2=A0

    Yes I highlighted that this was a new term. We ca= n deal with it as a separate issue indeed.=C2=A0

    =C2=A0

    Best

    Fabien

    =C2=A0

    On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer= <yaronf.ietf= @gmail.com> wrote:

    Hi Fabien,

    =C2=A0

    Yes, we definitely nee= d to reach closure on terminology, thank you for driving this discussion!

    =C2=A0

    One process comment: unless I=E2=80=99m missing something, the I= nteract (or Interaction) Server is not mentioned in the current draft. I su= ggest we do not introduce new functional components or new behaviors as par= t of the terminology discussion. Specifically, if the IS is useful, let=E2= =80=99s reach consensus on that separately. Then we can add it into the Ter= minology section.

    =C2=A0<= /u>

    Thanks,

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

    =C2=A0<= /u>

    From: <= /b>TXAuth <txauth-bounces@ietf.org> = on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    Date: Friday,= December 11, 2020 at 14:31
    To: Denis <denis.ietf@free.fr>
    Cc: G= NAP Mailing List <t= xauth@ietf.org>
    Subject: Re: [GNAP] Terminology proposal

    =C2=A0

    Hi Denis,=C2=A0<= /p>

    =C2=A0

    Thanks for your detailed feedback. My comments are embedded = into your message. Again those comments are my own, and we'll need to c= onverge to some consensus beyond what I say here. My main open question is = really about the RO being optional. Could you explain?

    =C2=A0

    Fabien=C2=A0

    =C2=A0

    On Fri, Dec 1= 1, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:

    This is a global response to the de= finitions proposal.

    =C2= =A0

    Termin= ology

    I propose to adopt the way ISO defines how to write the defini= tions.

    It is a single sentence that may be substituted to the wording being defined in the c= ontext of a sentence that uses that definition.
    Since this single sente= nce can be substituted to the wording, there is not point at the end of tha= t sentence. The sentence does not
    have a "a" or "the&quo= t; in front of it.

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

    [FI]=C2=A0In the first version, I was mostly= trying to not get too far away from the current text.=C2=A0But=C2=A0yes that's = a good idea, it gives a more formal rule, which has been proven to work.=C2= =A0

    =C2=A0

    If more infor= mation is useful to understand the wording, it is placed in one or more not= es afterwards.

    =C2=A0=

    Note: The ISO rules for dr= afting definitions are in the ISO/IEC Directives, Part 2 (edition 2018):=

    16.5.6=C2=A0=C2=A0=C2=A0 Definitions=

    The definition shall be written in such a form that= it can replace the term in its context. It shall not start with an article= (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end with a full stop. A definition shall not take the form of, or contain, a requirement.
    Only one definition per terminological entry is allowed. If a term is used= to define more than one concept, a separate terminological entry shall be = created
    for each concept and the domain shall be included in angle brac= kets before the definition.

    Circular definitions, which repeat the t= erm being defined, are not allowed.

    Comme= nts are inserted between the lines.

    =C2=A0

    Hello everyone,=C2= =A0

    =C2=A0

    <= /div>

    As an editor : a quick reminder that termi= nology=C2=A0issues will be discussed in the coming weeks, and we're exp= ecting your inputs right now (according to the process previously sent on t= he mailing list).

    =C2=A0=

    The rest of this message is a proposa= l written in my own name, and doesn't involve discussions with the edit= ors/chairs who might have different opinions.=C2=A0

    Authorization Server (AS)

    Manages the granting of privileges to a third-party= client instance. If the RO consents to at least a part of what is requeste= d, the AS issues an access token to the client.

    My questions: =

    - was else do we is= sue? (e.g. id claims, payment info, etc.) We could have more than access to= kens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I removed th= at for now.

    - there might potentially be several AS, currently we don=E2=80= =99t reflect that anywhere. If would leave that as an open item, depending = on what we end up doing in the spec

    I am not in favour of this definition: A= RO as defined later: "authorizes the request to access a protected re= source from the RS to the client".
    This does not mean in any way t= hat a RO has necessarily a direct relationship with one or more ASs. [FI] indeed we coul= d remove that limitation, to have a more general definition

    Using the ISO style for defini= tions, I propose:

    Authorization Server (AS): serv= er that grants rights and/or attributes to a particular end-user and that p= rovides them to a client in the form of an access token

    Since this definition is using the words "rights" and "attributes", these t= wo terms need to be defined as well.

    right: ability for an end-= user to perform a given operation on an object under the control of a RS

    attribute: property related to an end-user=

    = =C2=A0

    [FI] I like your proposal in general. There might be some discussi= ons on the details. I don't think it makes sense to grant "attribu= tes".=C2=A0=C2=A0=C2=A0

    Some explanations: a "right" is able to support a capability s= cheme. An "attribute" is able to support an ACL scheme.

    These two schemes are able to support "discretionary = access control" where the end-user has a "need-to-know".

    However, some attributes are also able to support wh= at=C2=A0 was called in the past "mandatory access control"; for e= xample,

    if the end-user is cleared to "top-s= ecret / marketing strategy".

    =C2=A0

    Interact Server (IS) - this is a new proposed term

    Manages the front-end interaction with the RO, in= order to gather its consent. Depending on the deployment model and the pri= vacy requirements,
    the IS may be a component of the AS, or may be disti= nct and managed by another party.

    Example : an IS usually involves a web interface acc= essed by RO through a web browser.

    Note : an IS is not always required, especially if= the access is granted through automated policies.

    =

    Using the ISO style for definition= s, I propose:

    =C2=A0<= u>

    Interaction Server (IS)

    component= from the AS or server interfacing with an AS that manages the interactions= with a RO, in order to gather its authorization

    <= h3 style=3D"margin-bottom:0in">Note : since the RO is an optional compo= nent, the IS is also an optional component.

    =C2=A0<= /p>

    [FI] indeed = IS is optional. note for myself when looking at RO : why is RO optional ?= =C2=A0=C2=A0

    Client

    Requests privileges from the AS, and uses access tokens at the RS. This sp= ecification differentiates between a specific instance (the client instance= , identified by its unique public key)
    and the software running the ins= tance (the client software). . For some kinds of client software, there cou= ld be many instances of a single piece of client software.
    The AS determ= ines which policies apply to a given client instance, including what it can= request and on whose behalf.

    Some comments: The above text is s= tating: "(the client instance, ide= ntified by its unique public key)".
    A client instance may use a pu= blic key, but that key is not necessarily unique, in particular when there = are multiple ASs.

    <= p class=3D"MsoNormal">[FI] yes, although when pos= sible I would still consider a better practice to expose a key to a specifi= c AS and not to the entire set of available ASs.=C2=A0=

    Example : a cli= ent can be a mobile application or a web application (the client software) = that requires authorizations from the RO to retrieve content from various p= rotected APIs. The client instance may for instance refer to a specific ver= sion of that client software.

    See on-going discussion : https://github.com/ietf-wg-gnap/= gnap-core-protocol/pull/132 (client instance).

    Using t= he ISO style for definitions, I propose:

    Client: application used by an end-user to interact with an AS or a = RS

    Note: a client can be a mobile ap= plication or a web application [FI] for me those are just examples, because there could = me more (ex IoT device)

    [FI] you remove = the entire discussion on client instance / client software, is that on purp= ose because you think it's not useful/right, or is it because of someth= ing else? (maybe add your comment of the related issue)=C2=A0 =C2=A0=

    Resource Server (RS)

    Accepts valid access tokens fr= om the client issued by the AS and serves protected resources on behalf of = the RO. There could be multiple RSs protected by the AS that the client may= call.

    Ex= ample : a RS is often composed of protected APIs that can be consumed by au= thorized client software.=C2=A0

    One comment: a RO is not necessarily involved. = [FI] a bit ha= rd to imagine, there's some kind of owner. Could you be more explicit?<= /span>

    Using the ISO s= tyle for definitions, I propose:

    Resource Server = (RS): server that accepts valid access tokens from clients issued by one or= more ASs which are used to grant or deny some requested operations<= u>

    Note: a RS is often composed of prote= cted APIs that can be consumed by clients.

    =C2=A0

    Reso= urce Owner (RO)

    Authorizes the request to access a protected resource from the RS t= o the client. The RO may decide to remove its consent at any time.

    Note : the RO may= be a physical person or may represent an organization.

    =C2=A0

    Two comments: In order to avoid confusion with the e= nd-user consent, the word " authorization" is being used instead = of "consent". [FI] ok=C2=A0

    It sh= ould be said that the RO is an optional component.=C2=A0[= FI] why? Using the ISO style for definitions, I propose:

    Resource Owner (RO): physical person acting on its own or rep= resenting an organization that authorizes to clients operations on protecte= d resources from a RS

    Note: Th= e RO is an optional component that may interact either with one RS or with = one or more ASs ,e.g. using an IS.

    End-user =E2=80=93 this was previously Requesting Party RQ<= u>

    A physical pers= on that operates and interacts with the client software. <= /u>

    Note : the end-user may or= may not be the same entity as the RO.

    The Note is slightly incorrect. the physical person may or may not be the same entity as the RO. [FI] I didn't understand your comment=

    Using the ISO style for definitions= , I propose:

    E= nd-user :=C2=A0 physical person that operates and interacts with the client= software

    Note : that physical person may or may not be the same entity as the RO. =

    =C2=A0

    Access Token<= u>

    A set of privil= eges delegated to the client instance for a specific end-user. An access to= ken is created by the AS, consumed and verified by the RS, and issued to an= d carried by the client's end-user on behalf of the RO. The contents an= d format of the access token are opaque to the client.=

    Example : JWT is a commonly u= sed format.

    Note 1 : an access token generally has a limited duration, after which = it may be refreshed at a regular interval.

    Note 2 : an access token may be revoked a= t any time by the RO.

    Note 3= : an access token may act as a capability or require an additional authent= ication by binding to a key

    A fundamental point: the third sentence from the definition states: &qu= ot;The contents and format of the acces= s token are opaque to the client".

    [FI] I= 'll check your other thread dedicated to that issue=C2=A0=

    See my other email sent today about &qu= ot;RS-Token Introspection or RC-Token Introspection" where I conclude:=

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For end-users cari= ng about their privacy (or for systems willing to protect the user's pr= ivacy), access tokens should not be considered
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to be opaque to R= Cs nor to RSs and ASs should not support Token Introspection, whether it is= RS-Token Introspection or RC-Token Introspection.

    =

    The example and the other N= otes above should be removed. If needed they should be placed in the main b= ody of the document.

    Using the ISO style fo= r definitions, I propose:

    Access Token : digitally signed data issued = by an Authorization Server (AS) and consumed by a Resource Server (RS)
    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that = contains rights and/or attributes grant= ed to a particular end-user

    =C2=A0

    Grant

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

    Using the ISO style for definitions, I propose:=

    Grant: permission given to end-user to use a subset of h= is rights and/or his attributes at a specific time and for a specific durat= ion

    =C2=A0

    Key

    A public cryptographic binding a request to the holder= of a private key. Access tokens and client instances can be associated wit= h specific keys at a point in time.

    Note : a key can be rotated or revoked by its h= older. The protocol supports the update of the key information. <= /u>

    "key"= is a general term that is well understood and that does not need to be def= ined. [FI] I = really wouldn't bet on that. We can reuse an existing definition but it= is a central piece so we need to be explicit

    The "definitions" section is not intended to expl= ain what can be done with the term that is being defined. [FI] ok we can work on that
    Until the word "key" is qualified using one or more= other terms, this definition should be removed.

    =C2=A0

    Reso= urce

    A p= rotected API served by the RS and accessed by the client if and only if acc= ess has been granted. Access to this resource is delegated by the RO as par= t of the grant process.

    The second sentence of the definition is not in accordan= ce with the ISO style or definitions and furthermore this second sentence s= hould be removed since a RO is an optional element.

    =C2=A0

    Using = the ISO style for definitions, I propose:

    Resource: protected API served by a RS and accessed by a client, if a= nd only if access is granted by an access token

    <= /blockquote>

    Subject Information

    Information about a subject (usually a RO) that is returned di= rectly to the client from the AS.

    Note : this information needs to be unique. =

    =C2=A0

    This defin= ition exhibits several problems:

    (1) The term "subject" is = not defined.

    (2) The information that is returned= is for an end-user, i.e. not fo= r "(usually a RO)".

    (3) The Note states : "thi= s information needs to be unique". Does it mean unique for the AS ? gl= obally unique ?

    = This definition should be revisited. [FI] I agree (I myself had many questions here)

    Denis

    =C2=A0

    = My questions :

    - probably we=E2=80=99d need to define subject<= u>

    Subject : https://open-measure.atlassian.net/wiki/spa= ces/DIC/pages/67600697/Subject+Dictionary+Entry

    - might be useful to clarify = the relationship to what identity providers do=C2=A0 <= /u>

    =C2=A0=

    =C2=A0

    Cheers

    Fabien

    =C2=A0=

    =C2=A0

    =

    =C2=A0

    =C2=A0

    =C2=A0

    --
    TXAuth ma= iling list
    TXAuth@i= etf.org
    https://www.ietf.org/mailman/listinfo/txauth

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

    --000000000000a261fc05b65d6d92-- From nobody Sun Dec 13 11:26:11 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6983A00E9 for ; Sun, 13 Dec 2020 11:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBEUxlyru8hM for ; Sun, 13 Dec 2020 11:26:06 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 7E8FA3A00E0 for ; Sun, 13 Dec 2020 11:26:05 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id 190so1648447wmz.0 for ; Sun, 13 Dec 2020 11:26:05 -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=FBesbCUn3r/ZBqtbSZCalILvxzBoKmXuRi34VVRbHMc=; b=ExxslItAjDXXXovrClLq/CH4RT8ZAodbbZwYbL6wFwIA/YVdP7McUqi/NGMdrZ34G2 1zzeSecXPD1qkAdZ9ES76CKvHtwFLqN7qG+HO9A10+1GVWRz0cnP56erXRagtGNu6OQ6 mK/fb5xVegUWlNLAbV4xreIdGj5Qaf4LVji/M/vjEseRRcaodEX0/RLxtnHJeWGe+urf 2SB1/vnUAkD8jtGP+Q1okjsf8/8Rv83DMu63O9n+mt0D/MTjutB39BANEtmm2x2qtbyc Akr4Y8XB2C4gWG8dwkNlQeKXzAIaz9q9J0x486V/2DE1O4uVK9CKzjnwprpJcl4yr1+V Ns3g== 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=FBesbCUn3r/ZBqtbSZCalILvxzBoKmXuRi34VVRbHMc=; b=JacPjo8jq9wgTP0fb6wOdWEyx9rHwn0MQyZCXBT/KMkKyLJtPPcVUMFWe+e36rp0+l 8IO6WDh/dwP7ZTnmjGzvK3xH4ZMK+030ZBdFtfPp9UWE5zwkTyq/QIS5TbHtNe0WOFBS GyXpxNn+A7V8Ua5p35oWEOju4xnON+YiJU1J1DczeaVxBbVsTUgfxU/ku3RllPU8jBSJ yJDOLqSds1dpDr5IXJ8DwaXWW+nmLRhKYDmphHYoMSVXdcYzuJhzkGuwS/s8Ypw/i7iS TVizf/CJtqWx3l/5m7JRLYQO/DtGPQS7f6nsIxV1vexcgLQR0EbmRrpx9My1D41LpHFZ lS1A== X-Gm-Message-State: AOAM533e6z+Jui9TQ42UA6m0A2QLVl76GRTFgM8Wc+4NRahKCr32CLcX PDvYort/nJQI5RI98t6RMQk= X-Google-Smtp-Source: ABdhPJxADxQeC84K0yI6ru3e+CkhM191nUsLioSuqI60PgbshTdO4dajnCrrBhOcUVBTl1a2gYOIAQ== X-Received: by 2002:a1c:2785:: with SMTP id n127mr263253wmn.148.1607887563716; Sun, 13 Dec 2020 11:26:03 -0800 (PST) Received: from [192.168.68.107] (bzq-79-178-108-177.red.bezeqint.net. [79.178.108.177]) by smtp.gmail.com with ESMTPSA id h83sm28831246wmf.9.2020.12.13.11.26.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Dec 2020 11:26:03 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Sun, 13 Dec 2020 21:26:00 +0200 From: Yaron Sheffer To: Fabien Imbault CC: Denis , GNAP Mailing List Message-ID: <4B381A4C-573A-41E0-BD9E-6B97187ED2D5@gmail.com> Thread-Topic: [GNAP] Terminology proposal References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> <13422918-A279-45FD-97B7-E02D74534960@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3690739562_533109037" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 19:26:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3690739562_533109037 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Fabien, =20 =E2=80=9CTypically=E2=80=9D means =E2=80=9Cusually, though there may be fully public resource= s where some operations don=E2=80=99t require any authorization, but I don=E2=80=99t wan= t a normative statement in the Terminology section=E2=80=A6=E2=80=9D =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Fabien Imbault Date: Sunday, December 13, 2020 at 21:21 To: Yaron Sheffer Cc: Denis , GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hi Yaron,=20 =20 Stylistic comments are very important too. And at some point we'll need a r= eview from native english speakers in the group (I'm sure Justin and Aaron w= ill be of great help here). =20 Just wondering: what do you mean by "typically"? (ideally I'd rather have a= definition which is not dependent on use case). =20 As soon as we land on something, I'll update the wiki. =20 Fabien =20 =20 =20 On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer wrote= : It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9Cserver that de= nies operations=E2=80=9D) a bit funny. How about: =20 Resource Server (RS) Definition: server that provides operations on protected resources; such op= erations typically require that the client provide valid access tokens issue= d by an AS Thanks, Yaron =20 From: Fabien Imbault Date: Sunday, December 13, 2020 at 13:20 To: Yaron Sheffer Cc: Denis , GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hello everyone,=20 =20 We're at the end of the 2 week period, and so I integrated the various feed= backs :=20 =20 a) from Yaron's feedback, removed new term "IS" and update issue https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle the proposal h= ere=20 b) integrated Tom's feedback regarding the RO (and moved to access token) c) definitions follow an ISO style as suggested by Denis, which we took as = a starting point (but I made the modifications I felt were necessary) =20 I modified the definitions, notes and examples as a consequence. You'll als= o find a summary of discussions for each term, so that we can keep track of = them too. =20 My biggest question is : what should we use as our main vocabulary between = privilege/rights/attribute? I tried to clarify, please let me know what you = think. The general idea is that we grant privileges that are delivered under= the form of access tokens (which contain rights and/or attributes). Regarding whether access tokens should be opaque or not, I suggest to remov= e that from the definition and handle that in issue https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/145 =20 All has been consolidated on the wiki too https://github.com/ietf-wg-gnap/g= nap-core-protocol/wiki/Terminology so that we have a clearer view of where w= e stand.=20 =20 Please comment further on the list if you have comments, I'll update if nec= essary (and refer to the mailing list url in the comment of the wiki update,= from now on). Then editors will review the proposal.=20 Here is a copy of https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/T= erminology#latest-discussion-update. =20 Latest discussion update Here we consolidate the latest proposal(s) from the group. We also include = the discussion items (individual feedbacks). Authorization Server (AS) Definition: server that grants privileges to a particular end-user and that= provides them to a client in the form of an access token Feedbacks / discussion / questions : Suggested "privilege" definition (that we would probably add as an addition= al sub-entry): "A privilege is the right to perform an operation (or action)= on a Resource." See also other def Note that we don't include claims in the definition (cf OIDC/SSI integratio= n), but since we talk about a "particular end-user" it is assumed somehow Denis suggested we used "rights and attributes" instead of privileges. [FI]= However i don't think one can really speak about granting attributes, excep= t indirectly (ABAC). See access token for more on that, where we can be more= specific. Do we allow cases such as distributing the AS on a mobile? (in this case we= 're at the limit of what we call a server) Client Definition: application used by an end-user to interact with an AS or a RS Note: this specification differentiates between a specific instance (the cl= ient instance, identified by its public key) and the software running the in= stance (the client software). For some kinds of client software, there could= be many instances of a single piece of client software. Example: a client can be a mobile application, a web application, etc. Feedbacks / discussion : Replaces previously proposed RC, we wouldn't provide a short name. Keep OAuth2 term, but we clarify it Further discussion on Client instance Resource Server (RS) Definition: server that denies operations on protected resources, unless th= e client provides valid access tokens issued by an AS Feedbacks / discussion : Denis suggests to make explicit that we could have several ASs - "issued by= one or more ASs" (also we'd need a convention on how to denote plural, e.g.= ASs). Not exactly sure right now of the multiple issuance would work, so ne= eds to be clarified. Also not sure if that's even necessary (do we lack in g= enerality if we keep the singular?) Resource Owner (RO) Definition: physical person acting on its own or representing an organizati= on, that may grant privileges on resources he has authority upon Note: the act of granting privileges may be manual (i.e. through an interac= tion) or automatic (i.e. through predefined rules). Feedbacks / discussion As some point we suggested "The RO may decide to remove its consent at any = time." Tom provided useful feedback on that. Moved to access token where it = fits more naturally. End-user Definition: physical person that operates with the client software Note: that physical person may or may not be the same entity as the RO Access token Definition: digitally signed data that contains specific rights and/or attr= ibutes Note 1: the access token can be issued to an end-user (usually requiring hi= s authentication) and subsequently refreshed. The AS usually provides a meth= od for the RO to revoke the privileges at any point in time. Note 2: an access token may act as a capability (i.e. bearer token) or requ= ire an additional authentication by binding to a key (i.e. bound token) Feedbacks / discussion Would require the subdefinitions right: ability for an end-user to perform = a given operation (or action) on a resource (or object) under the control of= a RS / attribute: property related to an end-user. Note 2 is here in relationship with PR 129 Grant Definition (verb): to permit, as a privilege given to an end-user to exerci= se some rights and/or assert attributes during a specific duration Definition (noun): the act of granting Key Definition: public cryptographic binding a request to the holder of a priva= te key, used by the protocol entities (AS, RS, client instance, bound token,= etc.) to identify themselves. Note: a key can be rotated or revoked by its holder. The protocol supports = the update of the key information. Feedbacks / discussion Denis thinks the term "key" is well understood and doesn't need to be defin= ed. Yet, I tend to believe we'd gain to keep it. First the generic term "key= " may be many things : symmetric/asymmetric, public/private, etc. It's also = useful to explain its use in the protocol Resource Definition: protected API served by a RS and accessed by a client, if and o= nly if a valid access token is provided =20 On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault w= rote: Hi Yaron,=20 =20 Yes I highlighted that this was a new term. We can deal with it as a separa= te issue indeed.=20 =20 Best Fabien =20 On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer wrote= : Hi Fabien, =20 Yes, we definitely need to reach closure on terminology, thank you for driv= ing this discussion! =20 One process comment: unless I=E2=80=99m missing something, the Interact (or Inter= action) Server is not mentioned in the current draft. I suggest we do not in= troduce new functional components or new behaviors as part of the terminolog= y discussion. Specifically, if the IS is useful, let=E2=80=99s reach consensus on = that separately. Then we can add it into the Terminology section. =20 Thanks, Yaron =20 From: TXAuth on behalf of Fabien Imbault Date: Friday, December 11, 2020 at 14:31 To: Denis Cc: GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hi Denis,=20 =20 Thanks for your detailed feedback. My comments are embedded into your messa= ge. Again those comments are my own, and we'll need to converge to some cons= ensus beyond what I say here. My main open question is really about the RO b= eing optional. Could you explain? =20 Fabien=20 =20 On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: This is a global response to the definitions proposal.=20 =20 Terminology I propose to adopt the way ISO defines how to write the definitions. It is a single sentence that may be substituted to the wording being define= d in the context of a sentence that uses that definition.=20 Since this single sentence can be substituted to the wording, there is not = point at the end of that sentence. The sentence does not=20 have a "a" or "the" in front of it. =20 [FI] In the first version, I was mostly trying to not get too far away from= the current text. But yes that's a good idea, it gives a more formal rule, = which has been proven to work.=20 =20 If more information is useful to understand the wording, it is placed in on= e or more notes afterwards. =20 Note: The ISO rules for drafting definitions are in the ISO/IEC Directives,= Part 2 (edition 2018): 16.5.6 Definitions The definition shall be written in such a form that it can replace the term= in its context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor= end with a full stop.=20 A definition shall not take the form of, or contain, a requirement. Only one definition per terminological entry is allowed. If a term is used = to define more than one concept, a separate terminological entry shall be cr= eated=20 for each concept and the domain shall be included in angle brackets before = the definition. Circular definitions, which repeat the term being defined, are not allowed. Comments are inserted between the lines. =20 Hello everyone, =20 =20 As an editor : a quick reminder that terminology issues will be discussed i= n the coming weeks, and we're expecting your inputs right now (according to = the process previously sent on the mailing list). https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology=20 =20 The rest of this message is a proposal written in my own name, and doesn't = involve discussions with the editors/chairs who might have different opinion= s. =20 Authorization Server (AS) Manages the granting of privileges to a third-party client instance. If the= RO consents to at least a part of what is requested, the AS issues an acces= s token to the client.=20 My questions:=20 - was else do we issue? (e.g. id claims, payment info, etc.) We could have = more than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I remo= ved that for now. - there might potentially be several AS, currently we don=E2=80=99t reflect that = anywhere. If would leave that as an open item, depending on what we end up d= oing in the spec I am not in favour of this definition: A RO as defined later: "authorizes t= he request to access a protected resource from the RS to the client".=20 This does not mean in any way that a RO has necessarily a direct relationsh= ip with one or more ASs. [FI] indeed we could remove that limitation, to hav= e a more general definition Using the ISO style for definitions, I propose: Authorization Server (AS): server that grants rights and/or attributes to a= particular end-user and that provides them to a client in the form of an ac= cess token Since this definition is using the words "rights" and "attributes", these t= wo terms need to be defined as well. right: ability for an end-user to perform a given operation on an object un= der the control of a RS attribute: property related to an end-user =20 [FI] I like your proposal in general. There might be some discussions on th= e details. I don't think it makes sense to grant "attributes". =20 Some explanations: a "right" is able to support a capability scheme. An "at= tribute" is able to support an ACL scheme.=20 These two schemes are able to support "discretionary access control" where = the end-user has a "need-to-know".=20 However, some attributes are also able to support what was called in the p= ast "mandatory access control"; for example,=20 if the end-user is cleared to "top-secret / marketing strategy". =20 Interact Server (IS) - this is a new proposed term Manages the front-end interaction with the RO, in order to gather its conse= nt. Depending on the deployment model and the privacy requirements,=20 the IS may be a component of the AS, or may be distinct and managed by anot= her party. Example : an IS usually involves a web interface accessed by RO through a w= eb browser.=20 Note : an IS is not always required, especially if the access is granted th= rough automated policies. Using the ISO style for definitions, I propose: =20 Interaction Server (IS)=20 component from the AS or server interfacing with an AS that manages the int= eractions with a RO, in order to gather its authorization Note : since the RO is an optional component, the IS is also an optional co= mponent. =20 [FI] indeed IS is optional. note for myself when looking at RO : why is RO = optional ? =20 Client=20 Requests privileges from the AS, and uses access tokens at the RS. This spe= cification differentiates between a specific instance (the client instance, = identified by its unique public key)=20 and the software running the instance (the client software). . For some kin= ds of client software, there could be many instances of a single piece of cl= ient software. The AS determines which policies apply to a given client instance, includin= g what it can request and on whose behalf. Some comments: The above text is stating: "(the client instance, identified= by its unique public key)".=20 A client instance may use a public key, but that key is not necessarily uni= que, in particular when there are multiple ASs. [FI] yes, although when possible I would still consider a better practice t= o expose a key to a specific AS and not to the entire set of available ASs.=20 Example : a client can be a mobile application or a web application (the cl= ient software) that requires authorizations from the RO to retrieve content = from various protected APIs. The client instance may for instance refer to a= specific version of that client software. See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protoco= l/pull/132 (client instance).=20 Using the ISO style for definitions, I propose: Client: application used by an end-user to interact with an AS or a RS Note: a client can be a mobile application or a web application [FI] for me= those are just examples, because there could me more (ex IoT device) [FI] you remove the entire discussion on client instance / client software,= is that on purpose because you think it's not useful/right, or is it becaus= e of something else? (maybe add your comment of the related issue) =20 Resource Server (RS) Accepts valid access tokens from the client issued by the AS and serves pro= tected resources on behalf of the RO. There could be multiple RSs protected = by the AS that the client may call. Example : a RS is often composed of protected APIs that can be consumed by = authorized client software. =20 One comment: a RO is not necessarily involved. [FI] a bit hard to imagine, = there's some kind of owner. Could you be more explicit? Using the ISO style for definitions, I propose: Resource Server (RS): server that accepts valid access tokens from clients = issued by one or more ASs which are used to grant or deny some requested ope= rations Note: a RS is often composed of protected APIs that can be consumed by clie= nts. =20 Resource Owner (RO) Authorizes the request to access a protected resource from the RS to the cl= ient. The RO may decide to remove its consent at any time. Note : the RO may be a physical person or may represent an organization. =20 Two comments: In order to avoid confusion with the end-user consent, the wo= rd " authorization" is being used instead of "consent". [FI] ok=20 It should be said that the RO is an optional component. [FI] why? Using the= ISO style for definitions, I propose: Resource Owner (RO): physical person acting on its own or representing an o= rganization that authorizes to clients operations on protected resources fro= m a RS Note: The RO is an optional component that may interact either with one RS = or with one or more ASs ,e.g. using an IS. End-user =E2=80=93 this was previously Requesting Party RQ A physical person that operates and interacts with the client software.=20 Note : the end-user may or may not be the same entity as the RO.=20 The Note is slightly incorrect. the physical person may or may not be the s= ame entity as the RO. [FI] I didn't understand your comment Using the ISO style for definitions, I propose: End-user : physical person that operates and interacts with the client sof= tware=20 Note : that physical person may or may not be the same entity as the RO.=20 =20 Access Token A set of privileges delegated to the client instance for a specific end-use= r. An access token is created by the AS, consumed and verified by the RS, an= d issued to and carried by the client's end-user on behalf of the RO. The co= ntents and format of the access token are opaque to the client. Example : JWT is a commonly used format.=20 Note 1 : an access token generally has a limited duration, after which it m= ay be refreshed at a regular interval. Note 2 : an access token may be revoked at any time by the RO.=20 Note 3 : an access token may act as a capability or require an additional a= uthentication by binding to a key=20 A fundamental point: the third sentence from the definition states: "The co= ntents and format of the access token are opaque to the client". [FI] I'll check your other thread dedicated to that issue=20 See my other email sent today about "RS-Token Introspection or RC-Token Int= rospection" where I conclude: For end-users caring about their privacy (or for systems willing to p= rotect the user's privacy), access tokens should not be considered to be opaque to RCs nor to RSs and ASs should not support Token Intro= spection, whether it is RS-Token Introspection or RC-Token Introspection. The example and the other Notes above should be removed. If needed they sho= uld be placed in the main body of the document. Using the ISO style for definitions, I propose:=20 Access Token : digitally signed data issued by an Authorization Server (AS)= and consumed by a Resource Server (RS)=20 that contains rights and/or attributes granted to = a particular end-user =20 Grant The process by which the client requests and is given delegated access to t= he RS by the AS through the authority of the RO. Using the ISO style for definitions, I propose: Grant: permission given to end-user to use a subset of his rights and/or hi= s attributes at a specific time and for a specific duration =20 Key A public cryptographic binding a request to the holder of a private key. Ac= cess tokens and client instances can be associated with specific keys at a p= oint in time.=20 Note : a key can be rotated or revoked by its holder. The protocol supports= the update of the key information.=20 "key" is a general term that is well understood and that does not need to b= e defined. [FI] I really wouldn't bet on that. We can reuse an existing defi= nition but it is a central piece so we need to be explicit The "definitions" section is not intended to explain what can be done with = the term that is being defined. [FI] ok we can work on that Until the word "key" is qualified using one or more other terms, this defin= ition should be removed. =20 Resource A protected API served by the RS and accessed by the client if and only if = access has been granted. Access to this resource is delegated by the RO as p= art of the grant process. The second sentence of the definition is not in accordance with the ISO sty= le or definitions and furthermore this second sentence should be removed sin= ce a RO is an optional element. =20 Using the ISO style for definitions, I propose:=20 Resource: protected API served by a RS and accessed by a client, if and onl= y if access is granted by an access token=20 Subject Information Information about a subject (usually a RO) that is returned directly to the= client from the AS. Note : this information needs to be unique.=20 =20 This definition exhibits several problems:=20 (1) The term "subject" is not defined.=20 (2) The information that is returned is for an end-user, i.e. not for "(usu= ally a RO)".=20 (3) The Note states : "this information needs to be unique". Does it mean u= nique for the AS ? globally unique ?=20 This definition should be revisited. [FI] I agree (I myself had many questi= ons here) Denis =20 My questions :=20 - probably we=E2=80=99d need to define subject Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697= /Subject+Dictionary+Entry - might be useful to clarify the relationship to what identity providers do= =20 =20 =20 Cheers Fabien =20 =20 =20 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3690739562_533109037 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable --B_3690739562_533109037-- From nobody Sun Dec 13 11:29:03 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2740A3A017E for ; Sun, 13 Dec 2020 11:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK7UnbncO4Ib for ; Sun, 13 Dec 2020 11:28:58 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6DB3A0114 for ; Sun, 13 Dec 2020 11:28:57 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id r17so13846613ilo.11 for ; Sun, 13 Dec 2020 11:28: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=r185Rd4NRI/5i7UnsPdkkF/aVFtePDtQMJwXiIC2cu8=; b=k79xI9RZwnzeh0kNb7tdklm4SFOFJFiBNp2S5clmtbJwlq6FG6+CaG2dJ0uqnrzwHG uA8GP3U6EvWzdGaBZRK7MrdgFrUWE4NBGGHiVGElz1FS0wT3vx7YCgWfoFOZPwR61nPU nQgjwuL5KWsKSiB/GpS/Xq5fAitklct/2ZTGZcf8lC0d463p/+SaugTYq9Kgxg+oJBLP b0g3s3hw/lgRmnkM94FERROt1SLCJrrT5ExAyCTny58Nf1WlNDAoms9BdIzvJt3WliAX 13e8gk9Ogz5n9uljOg2boqJfySYXrHbcAK8YhSAW/kPA4yN9VErQnwTChE4iS1BmoQ+S kjaA== 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=r185Rd4NRI/5i7UnsPdkkF/aVFtePDtQMJwXiIC2cu8=; b=G+7faOegysTDSLGpd7vSfeutWTrAPZofoVW0AQJmLpMutLyNECIDJoTmh+ah+SRO+X PPpSAlWEwK++DNG/SoFvqL1JfDD+Sv9EYv93MRpHRcLemSusWvnuDL5JYMh13mvAO8UG VWqx7AX75J+Rb3DCdn8NaFTeSJkqGUtSaWOzenOaCeWFmKFLaWzGczfifk875XdNEYcn tsmp034OC5aiQCqzF6TTatprDfb204+aTKGKrmZlWkoTl9hJm9g5Jwiq7hYKtyBw4DuV uw+LPFyTxydhJ3g2S61sNlRiQHEfB2JcnuJsNrXE2Ld11JZbK78k9JcyQM4nNRTMbYTQ +NlQ== X-Gm-Message-State: AOAM532MPzB9Eac3dF5NR/RqnE7xkN6nX1W7Cec72G0wjKhrSYQa3RIk 9SpBuR+dyJ/bYeFMQTCByjmex9S8jHDDQjAJ/WIVy5OVCI+79w== X-Google-Smtp-Source: ABdhPJw4DOgB8+9LIXt41yGHh6SJmYIrkkLtkEoRhQW76O7jWQN6cmiTAwvJPHHd2WpHu+WizSZPtZ6MJzooCIRgj0w= X-Received: by 2002:a92:6b05:: with SMTP id g5mr28853979ilc.289.1607887736547; Sun, 13 Dec 2020 11:28:56 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> <13422918-A279-45FD-97B7-E02D74534960@gmail.com> <4B381A4C-573A-41E0-BD9E-6B97187ED2D5@gmail.com> In-Reply-To: <4B381A4C-573A-41E0-BD9E-6B97187ED2D5@gmail.com> From: Fabien Imbault Date: Sun, 13 Dec 2020 20:28:45 +0100 Message-ID: To: Yaron Sheffer Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000602cec05b65d893d" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 19:29:02 -0000 --000000000000602cec05b65d893d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok but if we limit to protected resources, we don't have that problem, so typically is not needed. On Sun, Dec 13, 2020 at 8:26 PM Yaron Sheffer wrote= : > Hi Fabien, > > > > =E2=80=9CTypically=E2=80=9D means =E2=80=9Cusually, though there may be f= ully public resources > where some operations don=E2=80=99t require any authorization, but I don= =E2=80=99t want a > normative statement in the Terminology section=E2=80=A6=E2=80=9D > > > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Sunday, December 13, 2020 at 21:21 > *To: *Yaron Sheffer > *Cc: *Denis , GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hi Yaron, > > > > Stylistic comments are very important too. And at some point we'll need a > review from native english speakers in the group (I'm sure Justin and Aar= on > will be of great help here). > > > > Just wondering: what do you mean by "typically"? (ideally I'd rather have > a definition which is not dependent on use case). > > > > As soon as we land on something, I'll update the wiki. > > > > Fabien > > > > > > > > On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer > wrote: > > It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9C= server that > denies operations=E2=80=9D) a bit funny. How about: > > > Resource Server (RS) > > - Definition: server that provides operations on protected resources; > such operations typically require that the client provide valid access > tokens issued by an AS > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Sunday, December 13, 2020 at 13:20 > *To: *Yaron Sheffer > *Cc: *Denis , GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hello everyone, > > > > We're at the end of the 2 week period, and so I integrated the various > feedbacks : > > > > a) from Yaron's feedback, removed new term "IS" and update issue > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle > the proposal here > > b) integrated Tom's feedback regarding the RO (and moved to access token= ) > > c) definitions follow an ISO style as suggested by Denis, which we took a= s > a starting point (but I made the modifications I felt were necessary) > > > > I modified the definitions, notes and examples as a consequence. You'll > also find a summary of discussions for each term, so that we can keep tra= ck > of them too. > > > > My biggest question is : what should we use as our main vocabulary betwee= n > privilege/rights/attribute? I tried to clarify, please let me know what y= ou > think. The general idea is that we grant privileges that are delivered > under the form of access tokens (which contain rights and/or attributes). > > Regarding whether access tokens should be opaque or not, I suggest to > remove that from the definition and handle that in issue > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 > > > > All has been consolidated on the wiki too > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so > that we have a clearer view of where we stand. > > > > Please comment further on the list if you have comments, I'll update if > necessary (and refer to the mailing list url in the comment of the wiki > update, from now on). Then editors will review the proposal. > > Here is a copy of > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology#lates= t-discussion-update > . > > > Latest discussion update > > Here we consolidate the latest proposal(s) from the group. We also includ= e > the discussion items (individual feedbacks). > Authorization Server (AS) > > - Definition: server that grants privileges to a particular end-user > and that provides them to a client in the form of an access token > > Feedbacks / discussion / questions : > > - Suggested "privilege" definition (that we would probably add as an > additional sub-entry): "A privilege is the right to perform an operati= on > (or action) on a Resource." See also other def > > - Note that we don't include claims in the definition (cf OIDC/SSI > integration), but since we talk about a "particular end-user" it is as= sumed > somehow > - Denis suggested we used "rights and attributes" instead of > privileges. [FI] However i don't think one can really speak about gran= ting > attributes, except indirectly (ABAC). See access token for more on tha= t, > where we can be more specific. > - Do we allow cases such as distributing the AS on a mobile? (in this > case we're at the limit of what we call a server) > > Client > > - Definition: application used by an end-user to interact with an AS > or a RS > - Note: this specification differentiates between a specific instance > (the client instance, identified by its public key) and the software > running the instance (the client software). For some kinds of client > software, there could be many instances of a single piece of client > software. > - Example: a client can be a mobile application, a web application, > etc. > > Feedbacks / discussion : > > - Replaces previously proposed RC, we wouldn't provide a short name. > - Keep OAuth2 term, but we clarify it > - Further discussion on Client instance > > > Resource Server (RS) > > - Definition: server that denies operations on protected resources, > unless the client provides valid access tokens issued by an AS > > Feedbacks / discussion : > > - Denis suggests to make explicit that we could have several ASs - > "issued by one or more ASs" (also we'd need a convention on how to den= ote > plural, e.g. ASs). Not exactly sure right now of the multiple issuance > would work, so needs to be clarified. Also not sure if that's even > necessary (do we lack in generality if we keep the singular?) > > Resource Owner (RO) > > - Definition: physical person acting on its own or representing an > organization, that may grant privileges on resources he has authority = upon > - Note: the act of granting privileges may be manual (i.e. through an > interaction) or automatic (i.e. through predefined rules). > > Feedbacks / discussion > > - As some point we suggested "The RO may decide to remove its consent > at any time." Tom provided useful feedback > on > that. Moved to access token where it fits more naturally. > > End-user > > - Definition: physical person that operates with the client software > - Note: that physical person may or may not be the same entity as the > RO > > Access token > > - Definition: digitally signed data that contains specific rights > and/or attributes > - Note 1: the access token can be issued to an end-user (usually > requiring his authentication) and subsequently refreshed. The AS usual= ly > provides a method for the RO to revoke the privileges at any point in = time. > - Note 2: an access token may act as a capability (i.e. bearer token) > or require an additional authentication by binding to a key (i.e. boun= d > token) > > Feedbacks / discussion > > - Would require the subdefinitions right: ability for an end-user to > perform a given operation (or action) on a resource (or object) under = the > control of a RS / attribute: property related to an end-user. > - Note 2 is here in relationship with PR 129 > > > Grant > > - Definition (verb): to permit, as a privilege given to an end-user to > exercise some rights and/or assert attributes during a specific durati= on > - Definition (noun): the act of granting > > Key > > - Definition: public cryptographic binding a request to the holder of > a private key, used by the protocol entities (AS, RS, client instance, > bound token, etc.) to identify themselves. > - Note: a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > Feedbacks / discussion > > - Denis thinks the term "key" is well understood and doesn't need to > be defined. Yet, I tend to believe we'd gain to keep it. First the gen= eric > term "key" may be many things : symmetric/asymmetric, public/private, = etc. > It's also useful to explain its use in the protocol > > Resource > > - Definition: protected API served by a RS and accessed by a client, > if and only if a valid access token is provided > > > > On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault > wrote: > > Hi Yaron, > > > > Yes I highlighted that this was a new term. We can deal with it as a > separate issue indeed. > > > > Best > > Fabien > > > > On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer > wrote: > > Hi Fabien, > > > > Yes, we definitely need to reach closure on terminology, thank you for > driving this discussion! > > > > One process comment: unless I=E2=80=99m missing something, the Interact (= or > Interaction) Server is not mentioned in the current draft. I suggest we d= o > not introduce new functional components or new behaviors as part of the > terminology discussion. Specifically, if the IS is useful, let=E2=80=99s = reach > consensus on that separately. Then we can add it into the Terminology > section. > > > > Thanks, > > Yaron > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Friday, December 11, 2020 at 14:31 > *To: *Denis > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hi Denis, > > > > Thanks for your detailed feedback. My comments are embedded into your > message. Again those comments are my own, and we'll need to converge to > some consensus beyond what I say here. My main open question is really > about the RO being optional. Could you explain? > > > > Fabien > > > > On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: > > This is a global response to the definitions proposal. > > > TerminologyI propose to adopt the way ISO defines how to write the > definitions.It is a *single sentence* that may be substituted to the > wording being defined in the context of a sentence that uses that > definition. > Since this single sentence can be substituted to the wording, there is no= t > point at the end of that sentence. The sentence does not > have a "a" or "the" in front of it. > > > > [FI] In the first version, I was mostly trying to not get too far away > from the current text. But yes that's a good idea, it gives a more formal > rule, which has been proven to work. > > > > If more information is useful to understand the wording, it is placed in > one or more notes afterwards. > > > > Note: The ISO rules for drafting definitions are in the ISO/IEC > Directives, Part 2 (edition 2018): > > 16.5.6 Definitions > > The definition shall be written in such a form that it can replace the > term in its context. It shall not start with an article (=E2=80=9Cthe=E2= =80=9D, =E2=80=9Ca=E2=80=9D) nor > end with a full stop. > A definition shall not take the form of, or contain, a requirement. > > Only one definition per terminological entry is allowed. If a term is use= d > to define more than one concept, a separate terminological entry shall be > created > for each concept and the domain shall be included in angle brackets befor= e > the definition. > > Circular definitions, which repeat the term being defined, are not allowe= d. > > Comments are inserted between the lines. > > > > Hello everyone, > > > > As an editor : a quick reminder that terminology issues will be discussed > in the coming weeks, and we're expecting your inputs right now (according > to the process previously sent on the mailing list). > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 > > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > > > > The rest of this message is a proposal written in my own name, and doesn'= t > involve discussions with the editors/chairs who might have different > opinions. > Authorization Server (AS) > > Manages the granting of privileges to a third-party client instance. If > the RO consents to at least a part of what is requested, the AS issues an > access token to the client. > > *My questions: * > > *- was else do we issue? (e.g. id claims, payment info, etc.) We could > have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D = is not clear. I > removed that for now.* > > *- there might potentially be several AS, currently we don=E2=80=99t refl= ect that > anywhere. If would leave that as an open item, depending on what we end u= p > doing in the spec* > > I am not in favour of this definition: A RO as defined later: "authorizes > the request to access a protected resource from the RS to the client". > This does not mean in any way that a RO has necessarily a direct > relationship with one or more ASs. [FI] indeed we could remove that > limitation, to have a more general definition > Using the ISO style for definitions, I propose: > > Authorization Server (AS): server that grants rights and/or attributes to > a particular end-user and that provides them to a client in the form of a= n > access token > > Since this definition is using the words "rights" and "attributes", these > two terms need to be defined as well. > > right: ability for an end-user to perform a given operation on an object > under the control of a RS > > attribute: property related to an end-user > > > > [FI] I like your proposal in general. There might be some discussions on > the details. I don't think it makes sense to grant "attributes". > > Some explanations: a "right" is able to support a capability scheme. An > "attribute" is able to support an ACL scheme. > > These two schemes are able to support "discretionary access control" wher= e > the end-user has a "need-to-know". > > However, some attributes are also able to support what was called in the > past "mandatory access control"; for example, > > if the end-user is cleared to "top-secret / marketing strategy". > > > > Interact Server (IS) - this is a new proposed term > > Manages the front-end interaction with the RO, in order to gather its > consent. Depending on the deployment model and the privacy requirements, > the IS may be a component of the AS, or may be distinct and managed by > another party. > > Example : an IS usually involves a web interface accessed by RO through a > web browser. > > Note : an IS is not always required, especially if the access is granted > through automated policies. > > Using the ISO style for definitions, I propose: > > > > Interact*ion* Server (IS) > > component from the AS or server interfacing with an AS that manages the > interactions with a RO, in order to gather its authorizationNote : since > the RO is an optional component, the IS is also an optional component. > > > > [FI] indeed IS is optional. note for myself when looking at RO : why is R= O > optional ? > > Client Requests privileges from the AS, and uses access tokens at the RS. > This specification differentiates between a specific instance (the client > instance, identified by its unique public key) > and the software running the instance (the client software). . For some > kinds of client software, there could be many instances of a single piece > of client software. > The AS determines which policies apply to a given client instance, > including what it can request and on whose behalf. > > Some comments: The above text is stating: "(the client instance, > identified by its unique public key)". > A client instance may use a public key, but that key is not necessarily > unique, in particular when there are multiple ASs. > > [FI] yes, although when possible I would still consider a better practice > to expose a key to a specific AS and not to the entire set of available > ASs. > > Example : a client can be a mobile application or a web application (the > client software) that requires authorizations from the RO to retrieve > content from various protected APIs. The client instance may for instance > refer to a specific version of that client software. > > *See on-going discussion : > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 > (client > instance). * > > Using the ISO style for definitions, I propose: > > Client: application used by an end-user to interact with an AS or a RS > > Note: a client can be a mobile application or a web application [FI] for > me those are just examples, because there could me more (ex IoT device) > > [FI] you remove the entire discussion on client instance / client > software, is that on purpose because you think it's not useful/right, or = is > it because of something else? (maybe add your comment of the related > issue) > > Resource Server (RS) > > Accepts valid access tokens from the client issued by the AS and serves > protected resources on behalf of the RO. There could be multiple RSs > protected by the AS that the client may call. > > Example : a RS is often composed of protected APIs that can be consumed b= y > authorized client software. > > One comment: a RO is not necessarily involved. [FI] a bit hard to > imagine, there's some kind of owner. Could you be more explicit? > Using the ISO style for definitions, I propose: > > Resource Server (RS): server that accepts valid access tokens from client= s > issued by one or more ASs which are used to grant or deny some requested > operations > > Note: a RS is often composed of protected APIs that can be consumed by > clients. > > > > Resource Owner (RO) > > Authorizes the request to access a protected resource from the RS to the > client. The RO may decide to remove its consent at any time. > > Note : the RO may be a physical person or may represent an organization. > > > > Two comments: In order to avoid confusion with the end-user consent, the > word " authorization" is being used instead of "consent". [FI] ok > > It should be said that the RO is an optional component. [FI] why? Using > the ISO style for definitions, I propose: > > Resource Owner (RO): physical person acting on its own or representing an > organization that authorizes to clients operations on protected resources > from a RS > > Note: The RO is an optional component that may interact either with one R= S > or with one or more ASs ,e.g. using an IS. > > End-user =E2=80=93 this was previously Requesting Party RQ > > A physical person that operates and interacts with the client software. > > Note : the end-user may or may not be the same entity as the RO. > > The Note is slightly incorrect. the *physical person* may or may not be > the same entity as the RO. [FI] I didn't understand your comment > Using the ISO style for definitions, I propose: > > End-user : physical person that operates and interacts with the client > software > > Note : that physical person may or may not be the same entity as the RO. > > > > Access Token > > A set of privileges delegated to the client instance for a specific > end-user. An access token is created by the AS, consumed and verified by > the RS, and issued to and carried by the client's end-user on behalf of t= he > RO. The contents and format of the access token are opaque to the client. > > Example : JWT is a commonly used format. > > Note 1 : an access token generally has a limited duration, after which it > may be refreshed at a regular interval. > > Note 2 : an access token may be revoked at any time by the RO. > > Note 3 : an access token may act as a capability or require an additional > authentication by binding to a key > > A fundamental point: the third sentence from the definition states: "The > contents and format of the access token are opaque to the client". > > [FI] I'll check your other thread dedicated to that issue > > See my other email sent today about "RS-Token Introspection or RC-Token > Introspection" where I conclude: > > For end-users caring about their privacy (or for systems willing to > protect the user's privacy), access tokens should not be considered > to be opaque to RCs nor to RSs and ASs should not support Token > Introspection, whether it is RS-Token Introspection or RC-Token > Introspection. > > The example and the other Notes above should be removed. If needed they > should be placed in the main body of the document. > > Using the ISO style for definitions, I propose: > > Access Token : digitally signed data issued by an Authorization Server > (AS) and consumed by a Resource Server (RS) > that contains rights and/or attributes granted > to a particular end-user > > > > Grant > > The process by which the client requests and is given delegated access to > the RS by the AS through the authority of the RO. > > Using the ISO style for definitions, I propose: > > Grant: permission given to end-user to use a subset of his rights and/or > his attributes at a specific time and for a specific duration > > > > Key > > A public cryptographic binding a request to the holder of a private key. > Access tokens and client instances can be associated with specific keys a= t > a point in time. > > Note : a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > "key" is a general term that is well understood and that does not need to > be defined. [FI] I really wouldn't bet on that. We can reuse an existing > definition but it is a central piece so we need to be explicit > > The "definitions" section is not intended to explain what can be done wit= h > the term that is being defined. [FI] ok we can work on that > Until the word "key" is qualified using one or more other terms, this > definition should be removed. > > > > Resource > > A protected API served by the RS and accessed by the client if and only i= f > access has been granted. Access to this resource is delegated by the RO a= s > part of the grant process. > > The second sentence of the definition is not in accordance with the ISO > style or definitions and furthermore this second sentence should be remov= ed > since a RO is an optional element. > > > Using the ISO style for definitions, I propose: > > Resource: protected API served by a RS and accessed by a client, if and > only if access is granted by an access token > > Subject Information > > Information about a subject (usually a RO) that is returned directly to > the client from the AS. > > Note : this information needs to be unique. > > > > This definition exhibits several problems: > > (1) The term "subject" is not defined. > > (2) The information that is returned is for an end-user, i.e. not for "(u= sually > a RO)". > > (3) The Note states : "this information needs to be unique". Does it mean > unique for the AS ? globally unique ? > > This definition should be revisited. [FI] I agree (I myself had many > questions here) > > Denis > > > > *My questions : * > > *- probably we=E2=80=99d need to define subject* > > *Subject : > https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject= +Dictionary+Entry > * > > *- might be useful to clarify the relationship to what identity providers > do * > > > > > > 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 > > --000000000000602cec05b65d893d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ok but if we limit to protected resources, we don't ha= ve that problem, so typically is not needed.

    On Sun, Dec 13, 2020 at 8:26 PM= Yaron Sheffer <yaronf.ietf@gma= il.com> wrote:

    Hi Fabien,

    = =C2=A0

    =E2=80=9CTypically=E2=80=9D means = =E2=80=9Cusually, though there may be fully public resources where some ope= rations don=E2=80=99t require any authorization, but I don=E2=80=99t want a= normative statement in the Terminology section=E2=80=A6=E2=80=9D=

    =C2=A0

    Thanks,

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

    =C2=A0

    From: Fabien Imbault <fabien.imbault@gmail.com>
    Date: Su= nday, December 13, 2020 at 21:21
    To: Yaron Sheffer <yaronf.ietf@gmail.com&= gt;
    Cc: Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
    Subject:= Re: [GNAP] Terminology proposal

    =C2=A0

    Hi Yaron,=C2=A0

    =C2=A0

    Stylistic comments are = very important too. And at some point we'll need a review from native e= nglish speakers in=C2=A0the group (I'm sure Justin and Aaron will be of= great=C2=A0help here).

    = =C2=A0

    Just wondering: w= hat do you mean by "typically"? (ideally I'd rather have a de= finition which is not dependent on use case).

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

    As soon as we land on something, I'll update the wiki.

    =C2=A0

    =

    Fabien

    =C2=A0

    =C2= =A0

    =C2=A0

    On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffe= r <yaronf.iet= f@gmail.com> wrote:

    It=E2=80=99s purely stylistic, but I find th= e definition of RS (=E2=80=9Cserver that denies operations=E2=80=9D) a bit = funny. How about:

    =C2=A0<= /u>

    Resource Server (RS)=

    • Definition: server that provides operati= ons on protected resources; such operations typically require that the clie= nt provide valid access tokens issued by an AS

      • Thanks,

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

      =C2=A0=

      From: <= span style=3D"font-size:12pt;color:black">Fabien Imbault <fabien.imbault@gmail.com>
      Date: Sunday, December 13, 2020 at 13:20
      To: Yaro= n Sheffer <      ya= ronf.ietf@gmail.com>
      Cc: Denis <denis.ietf@free.fr>, GNAP Mailing L= ist <txauth@ietf.or= g>
      Subject: Re: [GNAP] Terminology proposal<= u>

      =C2=A0

      <= div>

      Hello everyone,=C2=A0

      =C2=A0

      We're at the end of the 2 week period, and so I integrated the variou= s feedbacks :=C2=A0

      =C2= =A0

      a) from Yaron's = feedback, removed new term "IS" and update issue=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to = handle the proposal here=C2=A0

      b) integrated Tom's feedback regarding the RO (and moved=C2=A0 t= o access token)

      c) defin= itions follow an ISO style as suggested by Denis, which we took as a starti= ng point (but I made the=C2=A0modifications I felt were necessary)

      =C2=A0

      I modified the definitions, notes and examples as= a consequence. You'll also find a summary of discussions for each term= , so that we can keep track of them too.

    =C2=A0

    = My biggest question is : what should we use as our main vocabulary between = privilege/rights/attribute? I tried to clarify, please let me know what you= think. The general idea is that we grant privileges that are delivered und= er the form of access tokens (which contain rights and/or attributes).

    Regarding whether access tok= ens should be opaque or not, I suggest to remove that from the definition a= nd handle that in issue=C2=A0https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/145

    =C2=A0

    Al= l has been consolidated on the wiki too=C2=A0https:/= /github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so that we= have a clearer view of where we stand.=C2=A0

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

    Please comment further on the list if you have comments,=C2=A0I'll= update if necessary (and refer to the mailing list url in the comment of t= he wiki update, from now on). Then editors will review the proposal.=C2=A0<= u>

    Here is a copy of=C2=A0<= a href=3D"https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminolo= gy#latest-discussion-update" target=3D"_blank">https://github.com/ietf-wg-g= nap/gnap-core-protocol/wiki/Terminology#latest-discussion-update.

    =C2=A0

    Latest di= scussion update

    Here we consolidate the latest prop= osal(s) from the group. We also include the discussion items (individual fe= edbacks).

    Authorization Server (AS)

    • Definition: server that grants privileges to a particular end= -user and that provides them to a client in the form of an access token

    Feedbacks / discussion / questions :

    • Suggested "privilege" definition= (that we would probably add as an additional sub-entry): "A privilege= is the right to perform an operation (or action) on a Resource." See = also=C2=A0other def
    • Note that we don't include claims= in the definition (cf OIDC/SSI integration), but since we talk about a &qu= ot;particular end-user" it is assumed somehow
    • Denis suggested we used "rights and attributes" = instead of privileges. [FI] However i don't think one can really speak = about granting attributes, except indirectly (ABAC). See access token for m= ore on that, where we can be more specific.
    • Do we allow cases such as distributing the AS on a mobile? (in th= is case we're at the limit of what we call a server)

    Cli= ent

    • Definition: application use= d by an end-user to interact with an AS or a RS
      • Note: this specification differentiates between a specific in= stance (the client instance, identified by its public key) and the software= running the instance (the client software). For some kinds of client softw= are, there could be many instances of a single piece of client software.
    • Example: a client can be a mobile ap= plication, a web application, etc.

    Feedbacks= / discussion :

    • Replaces previo= usly proposed RC, we wouldn't provide a short name.
    • Keep OAuth2 term, but we clarify it<= /u>
    • Further discussion on=C2=A0Client in= stance

    Resource Server (RS)

  • Definition: server that denies operations on protected reso= urces, unless the client provides valid access tokens issued by an AS

    • Feedbacks / discussion :

    =
    • Denis suggests to make explicit that we could have sever= al ASs - "issued by one or more ASs" (also we'd need a conven= tion on how to denote plural, e.g. ASs). Not exactly sure right now of the = multiple issuance would work, so needs to be clarified. Also not sure if th= at's even necessary (do we lack in generality if we keep the singular?)=

    Resource Owner (RO)

    • Definition: physical person acting on its own or representing an organ= ization, that may grant privileges on resources he has authority upon
    • Note: the act of granting privileges ma= y be manual (i.e. through an interaction) or automatic (i.e. through predef= ined rules).

    Feedbacks / discussion=

    • As some point we suggested "The RO = may decide to remove its consent at any time." Tom provided=C2=A0useful feedback=C2=A0on that. Moved to access t= oken where it fits more naturally.

    End-user

    • Definition: physical person that operates with= the client software
    • Note: that = physical person may or may not be the same entity as the RO

    = Access token

    • Definition: digita= lly signed data that contains specific rights and/or attributes
    • Note 1: the access token can be issued to an = end-user (usually requiring his authentication) and subsequently refreshed.= The AS usually provides a method for the RO to revoke the privileges at an= y point in time.
    • Note 2: an access= token may act as a capability (i.e. bearer token) or require an additional= authentication by binding to a key (i.e. bound token)=

    Feedbacks / discussion

    • Note 2 is here in relationship with=C2=A0PR 129

    Grant

    • Definition (verb): to permit, as a privilege given to an end-user to exe= rcise some rights and/or assert attributes during a specific duration
    • Definition (noun): the act of granting<= /span>

    Key

    • Definition:= public cryptographic binding a request to the holder of a private key, use= d by the protocol entities (AS, RS, client instance, bound token, etc.) to = identify themselves.
    • Note: a key= can be rotated or revoked by its holder. The protocol supports the update = of the key information.

    Feedbacks / discussio= n

    • Denis thinks the term "= key" is well understood and doesn't need to be defined. Yet, I ten= d to believe we'd gain to keep it. First the generic term "key&quo= t; may be many things : symmetric/asymmetric, public/private, etc. It's= also useful to explain its use in the protocol

      • Resource

      • Definition: protected API served b= y a RS and accessed by a client, if and only if a valid access token is pro= vided

    =C2= =A0

    On Fri, Dec 11, 2020 = at 6:05 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    <= /div>

    Hi Yaron,=C2=A0=

    =C2=A0

    Yes I highlighted that this was a new term. We can deal with= it as a separate issue indeed.=C2=A0

    =C2=A0

    Be= st

    Fabien<= /p>

    =C2=A0

    On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer <yaronf.ietf@gmail.com= > wrote:

    Hi Fabien,

    =C2=A0<= u>

    Yes, we definitely need to reach closure o= n terminology, thank you for driving this discussion!

    =C2=A0

    One proce= ss comment: unless I=E2=80=99m missing something, the Interact (or Interact= ion) Server is not mentioned in the current draft. I suggest we do not intr= oduce new functional components or new behaviors as part of the terminology= discussion. Specifically, if the IS is useful, let=E2=80=99s reach consens= us on that separately. Then we can add it into the Terminology section.<= /u>

    =C2=A0

    Thanks,

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

    =C2=A0

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Im= bault <fab= ien.imbault@gmail.com>
    Date: Friday, December 11, 2020 at = 14:31
    To: Denis <denis.ietf@free.fr>
    Cc: GNAP Mailing List <= txauth@ietf.org>= ;
    Subject: Re: [GNAP] Terminology proposal

    =C2=A0

    Hi Denis,=C2=A0

    =C2=A0

    Thanks = for your detailed feedback. My comments are embedded into your message. Aga= in those comments are my own, and we'll need to converge to some consen= sus beyond what I say here. My main open question is really about the RO be= ing optional. Could you explain?

    =C2=A0

    Fabien= =C2=A0

    =C2=A0=

    On Fri, Dec 11, 2020 at 12:08 PM D= enis <denis.ietf= @free.fr> wrote:

    This is a global response to the definitions proposal.

    =C2=A0

    <= /div>

    Terminology=

    I propose = to adopt the way ISO defines how to write the definitions.=

    It is a single sentence that may be= substituted to the wording being defined in the context of a sentence that= uses that definition.
    Since this single sentence can be substituted to= the wording, there is not point at the end of that sentence. The sentence = does not
    have a "a" or "the" in front of it.    =

    =C2= =A0

    [FI]=C2=A0In the first version, I was mostly trying to not get too fa= r away from the current text.=C2=A0But=C2=A0yes that's a good idea, it gives a m= ore formal rule, which has been proven to work.=C2=A0<= /p>

    =C2=A0

    If more information is useful to under= stand the wording, it is placed in one or more notes afterwards.<= /u>

    =C2=A0

    Note: The ISO rules for drafting definitions are in= the ISO/IEC Directives, Part 2 (edition 2018):

    16.5.6=C2=A0=C2=A0=C2=A0 Definitions

    T= he definition shall be written in such a form that it can replace the term = in its context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, = =E2=80=9Ca=E2=80=9D) nor end with a full stop.
    A definition shall not t= ake the form of, or contain, a requirement.

    Only one definition per = terminological entry is allowed. If a term is used to define more than one = concept, a separate terminological entry shall be created
    for each conc= ept and the domain shall be included in angle brackets before the definitio= n.

    Circular definitions, which repeat the term being defined, are no= t allowed.

    = Comments are inserted between = the lines.

    =C2=A0=

    Hello everyone,=C2=A0

    =C2=A0

    As an editor : a quick reminder that terminology=C2=A0issues will b= e discussed in the coming weeks, and we're expecting your inputs right = now (according to the process previously sent on the mailing list).<= u>

    https://github.com/ietf-wg= -gnap/gnap-core-protocol/wiki/Terminology=C2=A0

    =

    =C2=A0

    The rest of this message is a proposal written in my own name, a= nd doesn't involve discussions with the editors/chairs who might have d= ifferent opinions.=C2=A0

    Authorization Server = (AS)

    Man= ages the granting of privileges to a third-party client instance. If the RO= consents to at least a part of what is requested, the AS issues an access = token to the client.

    My questions:

    - was else do we issue? (e.g. id claims, payme= nt info, etc.) We could have more than access tokens, but =E2=80=9Cdirected= information=E2=80=9D is not clear. I removed that for now.

    - there might pot= entially be several AS, currently we don=E2=80=99t reflect that anywhere. I= f would leave that as an open item, depending on what we end up doing in th= e spec

    I am not in favour of this definition: A RO as defined later: "a= uthorizes the request to access a protected resource from the RS to the cli= ent".
    This does not mean in any way that a RO has necessarily a di= rect relationship with one or more ASs.     [FI] indeed we could remove that limitation, to = have a more general definition

    Using the ISO style for definitions, I propose:

    Authorization Server (AS): server that grants rights and/or = attributes to a particular end-user and that provides them to a client in t= he form of an access token

    Since this= definition is using the words "ri= ghts" and "attributes", these two terms need to be defined a= s well.

    right: ability for an end-user to perform a given opera= tion on an object under the control of a RS

    attrib= ute: property related to an end-user

    <= /div>

    =C2=A0

    [FI] I like your pro= posal in general. There might be some discussions on the details. I don'= ;t think it makes sense to grant "attributes".=C2=A0=C2=A0= =C2=A0

    Some explanations: a "= ;right" is able to support a capability scheme. An "attribute&quo= t; is able to support an ACL scheme.

    These two sc= hemes are able to support "discretionary access control" where th= e end-user has a "need-to-know".

    Howeve= r, some attributes are also able to support what=C2=A0 was called in the pa= st "mandatory access control"; for example, =

    if the end-user is cleared to "top-secret / marketing strategy&qu= ot;.

    =C2=A0

    Interact Server (IS) - this is a new propose= d term

    Man= ages the front-end interaction with the RO, in order to gather its consent.= Depending on the deployment model and the privacy requirements,
    the IS= may be a component of the AS, or may be distinct and managed by another pa= rty.

    Exampl= e : an IS usually involves a web interface accessed by RO through a web bro= wser.

    Note= : an IS is not always required, especially if the access is granted throug= h automated policies.

    Using the ISO style for definitions, I propose:

    =C2=A0

    I= nteraction Server (IS)

    component from the AS or server inter= facing with an AS that manages the interactions with a RO, in order to gath= er its authorization

    Note : since the RO is an optional component, the IS is also an opti= onal component.

    =C2=A0

    [FI] indeed IS is optional. note for mys= elf when looking at RO : why is RO optional ?=C2=A0=C2=A0<= /u>

    <= span style=3D"font-size:10pt;line-height:125%;font-family:Arial,sans-serif;= color:rgb(36,41,46)">Client=

    Requests privileges from the = AS, and uses access tokens at the RS. This specification differentiates bet= ween a specific instance (the client instance, identified by its unique pub= lic key)
    and the software running the instance (the client software). .= For some kinds of client software, there could be many instances of a sing= le piece of client software.
    The AS determines which policies apply to a= given client instance, including what it can request and on whose behalf.<= /span>

    Some comments: The above text is stating: "(the client instance, identified by its unique public k= ey)".
    A client instance may use a public key, but that key is not = necessarily unique, in particular when there are multiple ASs.

    [FI] yes, although when possible I would still consider a= better practice to expose a key to a specific AS and not to the entire set= of available ASs.=C2=A0

    Example : a client can be a mobile applicatio= n or a web application (the client software) that requires authorizations f= rom the RO to retrieve content from various protected APIs. The client inst= ance may for instance refer to a specific version of that client software.<= /span>

    <= i>See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance).

    =

    Using the ISO style for definitions, I = propose:

    Client: application used = by an end-user to interact with an AS or a RS

    Note: a client can be a mobile application or a web application <= /span>[FI] for me th= ose are just examples, because there could me more (ex IoT device)

    [FI] you remove the entire discussion on client = instance / client software, is that on purpose because you think it's n= ot useful/right, or is it because of something else? (maybe add your commen= t of the related issue)=C2=A0 =C2=A0

    =

    = Resource Server (RS)

    Accepts valid access tokens from the client issued by the AS a= nd serves protected resources on behalf of the RO. There could be multiple = RSs protected by the AS that the client may call.

    <= p style=3D"margin-bottom:12.25pt;line-height:150%">Example : a RS is often composed o= f protected APIs that can be consumed by authorized client software.=C2=A0 =

    One = comment: a RO is not necessarily involved. [FI] a bit hard to imagine, there's some = kind of owner. Could you be more explicit?

    Using the ISO style for definitions, I propose:=

    Resource Server (RS): server that accepts valid = access tokens from clients issued by one or more ASs which are used to gran= t or deny some requested operations

    Note: a RS is often composed of protected APIs that can be consumed b= y clients.

    =C2=A0

    Resource Owner (RO)=

    Authorizes the request t= o access a protected resource from the RS to the client. The RO may decide = to remove its consent at any time.

    Note : the RO may be a physical person or may rep= resent an organization.

    =C2=A0

    Two comme= nts: In order to avoid confusion with the end-user consent, the word "= authorization" is being used instead of "consent". <= span style=3D"font-family:Arial,sans-serif;color:red">[FI] ok=C2=A0<= u>

    It should be said that the RO is an o= ptional component.=C2=A0[FI] why? Using the ISO st= yle for definitions, I propose:

    Resource Owner (= RO): physical person acting on its own or representing an organization that= authorizes to clients operations on protected resources from a RS

    Note: The RO is an optional component = that may interact either with one RS or with one or more ASs ,e.g. using an= IS.

    End-user =E2=80=93 th= is was previously Requesting Party RQ

    A physical person that operates and interacts= with the client software.

    Note : the end-user may or may not be the same entity as= the RO.

    The Note is sli= ghtly incorrect. the physical person= may or may not be the same = entity as the RO. [FI] I didn't unders= tand your comment

    Using the ISO style for definitions, I propose:<= /u>

    End-user :=C2=A0 physical perso= n that operates and interacts with the client software

    Note : that physical person may or = may not be the same entity as the RO.

    =C2=A0

    Access Token

    A set of privileges delegated to the client i= nstance for a specific end-user. An access token is created by the AS, cons= umed and verified by the RS, and issued to and carried by the client's = end-user on behalf of the RO. The contents and format of the access token a= re opaque to the client.

    Example : JWT is a commonly used format. <= /u>

    Note 1 : an access token g= enerally has a limited duration, after which it may be refreshed at a regul= ar interval.

    Note 2 : an access token may be revoked at any time by the RO. <= u>

    Note 3 : an access token may act as = a capability or require an additional authentication by binding to a key

    A fundamental point: the t= hird sentence from the definition states: "The contents and format of the access token are opaque to the clie= nt".

    [FI] I'll check your other thr= ead dedicated to that issue=C2=A0

    See my other email sent today about "RS-Token Introspection or= RC-Token Introspection" where I conclude:

    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For end-users caring about their privacy (or= for systems willing to protect the user's privacy), access tokens shou= ld not be considered
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to be opaque to RCs nor to RSs and ASs shou= ld not support Token Introspection, whether it is RS-Token Introspection or= RC-Token Introspection.

    The example and the other Notes above should be remov= ed. If needed they should be placed in the main body of the document.

    Using the ISO style for definitions, I propose:<= /span>

    Access Token : digitally signed data issued by an Authorization Server (= AS) and consumed by a Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that contains rights and/or attributes granted to a particular end-user=

    =C2=A0<= u>

    Grant

    The process by which the client requests and is given delegated access= to the RS by the AS through the authority of the RO.<= /p>

    Using the I= SO style for definitions, I propose:

    Grant: per= mission given to end-user to use a subset of his rights and/or his attribut= es at a specific time and for a specific duration

    =C2=A0

    Key<= /span>

    A public= cryptographic binding a request to the holder of a private key. Access tok= ens and client instances can be associated with specific keys at a point in= time.

    N= ote : a key can be rotated or revoked by its holder. The protocol supports = the update of the key information.

    "key" is a general term that is we= ll understood and that does not need to be defined. [FI] I really wouldn't bet on th= at. We can reuse an existing definition but it is a central piece so we nee= d to be explicit

    The "def= initions" section is not intended to explain what can be done with the= term that is being defined. [FI] ok we can work on that
    Until the word = "key" is qualified using one or more other terms, this definition= should be removed.

    =C2=A0

    Resource

    A protected API served by the RS= and accessed by the client if and only if access has been granted. Access = to this resource is delegated by the RO as part of the grant process.

    = The second= sentence of the definition is not in accordance with the ISO style or defi= nitions and furthermore this second sentence should be removed since a RO i= s an optional element.

    =C2=A0=

    Using the ISO style for definitions= , I propose: =

    Resource: protected API= served by a RS and accessed by a client, if and only if access is granted = by an access token

    Subject Information

    Information ab= out a subject (usually a RO) that is returned directly to the client from t= he AS.

    Note := this information needs to be unique.

    =

    =C2=A0

    This definition exhibits several prob= lems:

    (1) The term "subject" is not defined. =

    (2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

    (3) The Note states : "this information needs to be u= nique". Does it mean unique for the AS ? globally unique ? <= /u>

    This definition should be r= evisited. [FI= ] I agree (I myself had many questions here)

    Den= is

    =

    =C2=A0<= /u>

    My questions : <= u>

    - probably we=E2= =80=99d need to define subject

    Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Sub= ject+Dictionary+Entry

    - might be useful to clarify the relationship to what i= dentity providers do=C2=A0

    =C2=A0

    =C2=A0

    Cheer= s

    Fabien

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0=

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

    <= /div>

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

    --000000000000602cec05b65d893d-- From nobody Sun Dec 13 12:20:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15263A083C for ; Sun, 13 Dec 2020 12:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhbgodk7Ii_n for ; Sun, 13 Dec 2020 12:20:39 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE333A083E for ; Sun, 13 Dec 2020 12:20:38 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id a12so25001700lfl.6 for ; Sun, 13 Dec 2020 12:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=P6LvixkQAAk7eSiRS6wK4hlmyevYGW8+NrEi5rzkSr4=; b=kStK1wdqTOtOxUfKFUUcuU4gjb1bqyWYMiS3kirFx0wROJ8Uq1NvPfF5K7aMnj7vmL nGGHGBxC9sKauVrzCmYT8NJt1Bk3XF/xEMS6ouI56teNHzdvUEaTzFJr3Xk79//rSqjL CVlhaYT06NHutworbZw8wmR3XvmXIDP1uQp3Fv9rhLFfKWSRdKlAqveUMkryt15VL3rS gLVltVvpX8Ohu3zd0zUo72Dz9G1cqnc2GXKFdh94BHvP+AvdqU446gWwdbIgEO5V/rrp u3qe5NuYW4xA+O2ffTFhchV9pVDS+5/1b1Gu2hS/p7mrqtJc8h5wWmZuvvw2CE1F1inB sX4Q== 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=P6LvixkQAAk7eSiRS6wK4hlmyevYGW8+NrEi5rzkSr4=; b=mTflTPHwAtlviw7CWoD1UmP6oeCsXHilm49m4ccZc6wZtHCs/Mpsm7va3ARFsm1dDO Qtwm+DscKQ/AcSUWCU5YPziTKyl81c8IADRFptdlphujVNxMxhi60ZRDWQp+rF9eij++ edNuoeT+MrYz8EzVT7qbZtUx4WGTE2TrI3B+ezjfuL4VjWqKMcW8Ouu1tPbz5t+rATFa fgkTjT/3jkUNih6DywyRs1EOerdzOPEvf2lngjeAOxARb4GrBAF2Lu9kFw/OEC+bQpo+ JetgeXvNVgVPPLrUwXtVHyIg9+Yi9X8dC65sHR/aNByP2g7zuFbBOpnkSUJlsgJIuJKU ZD9w== X-Gm-Message-State: AOAM530ZbLM2frY8VbeJn+8pugPk5faDI0BmCjkN/+ZPWlioPnVpE1Er gsYzuqGHLXVDZAkdb+ycWPd6rcC+CFqXR5Y3lMJmJkS5G0cPew== X-Google-Smtp-Source: ABdhPJxC9osZrwI5e2DO1BFZ3KJC/gqgclJEBARFbXUx4OBS5RaUyYshkBggD5qB9voq/LYVxWlxv8WmICOFFZSQb4Y= X-Received: by 2002:a19:2d4:: with SMTP id 203mr8088021lfc.303.1607890836467; Sun, 13 Dec 2020 12:20:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jim Willeke Date: Sun, 13 Dec 2020 15:20:00 -0500 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000254ca905b65e42ab" Archived-At: Subject: Re: [GNAP] physical person 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, 13 Dec 2020 20:20:41 -0000 --000000000000254ca905b65e42ab Content-Type: text/plain; charset="UTF-8" A natural person is usually implied to be a Human Being. As in jurisprudence, fundamental human rights are implicitly granted only to Natural Persons. A person or entity seems to be more appropriate. -- -jim Jim Willeke On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault wrote: > Hi, > > Wasn't thinking about that, but yes. > Natural person would be good. I change it in the wiki. > > Thxs > Fabien > > On Sun, Dec 13, 2020 at 7:07 PM Tom Jones > wrote: > >> I dislike this. A robot can be a physical person. What's wrong with >> natural person that others use? >> Peace ..tom >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000254ca905b65e42ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    A natural person is usually implied to be a Human Being.As in jurisprudence, fundament= al human rights are implicitly granted only to Natural Persons.

    A person or entity seems to be more appropriate= .

    --
    -jim<= br>Jim Willeke


    On Sun, Dec 13, 2020 at 1:44 PM = Fabien Imbault <fabien.imbau= lt@gmail.com> wrote:
    Hi,=C2=A0

    Wasn't thinki= ng=C2=A0about that, but yes.
    Natural person would be good. I chan= ge it in the wiki.=C2=A0

    Thxs
    Fabien

    On Sun, Dec 13, 2020 at 7:07 PM Tom Jones <thomasclinganjones@gmail.com>= wrote:
    I dislike this. A robo= t can be a physical person. What's wrong with natural person that other= s use?
    Peace ..tom
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000254ca905b65e42ab-- From nobody Sun Dec 13 12:23:34 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E0E3A0858 for ; Sun, 13 Dec 2020 12:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP5DkV0BLU_u for ; Sun, 13 Dec 2020 12:23:32 -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 551023A0855 for ; Sun, 13 Dec 2020 12:23:32 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id i18so14933368ioa.1 for ; Sun, 13 Dec 2020 12:23:32 -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=P7S9LZqUsB9ERyIIxzFn14sT2Kth+FXDtyD06WgeEHE=; b=Z0b+D1yYhwU7T6Xc0z2fYzIeH8c8HJvHMSdxuAQi72LJUiD6hhLdRk2lVZZpD/icC4 HKyvdhX2yWIb7rztbdM/F7X+SZCy11dTPwekz+1yOJyof3yrs/k6mi/2n08BrGdvXLY6 kkkQejDfM6X0SGgdv8juGjSSimh9U9P6qRle3jyKGlhtlev5Gm8NSkrj3NfDxTQ02EbH vQw2KbRUew2+XOH5p3dfBFdo8LYAjDHs4WoORimNvCPBjuKvv6Xcid8YkhrvUnzMVRh/ IMV6clUJkodizJ7/Y0NLkM2SytbQfSs73hd3Lg/UjhoKUtyhzl6OjGMFd5Afou2yhR3X Ngkw== 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=P7S9LZqUsB9ERyIIxzFn14sT2Kth+FXDtyD06WgeEHE=; b=V0bDV2woB1epFwiz5YIbdNnv0rqvG4BRJlDXKG0n08acki/vqxIheOEz9/z1+cjhZA v8fHDpra/9CpewuiCPe+EXNXvokYtxAjXibcy57lbwH0DsMgH+FpcUpy6FJQfra779ul hRMBag9QBuw3JQEhqF8Q/yo33KuqBAr4nI5Oga/mS5fLuAIyLnSqk77+BFLfB5sWXOj+ EC2qLZcPss2JioJDM4pNIazoG6XNEtmKhfYyA7jdarKvFM8EkZmo2hYlOn/zg1lVe9Nf 4gfC/5Mg+QmeF10vuSl0LNVPXHWTFzzSTw563j9A1tjd/9csbKk7wWC92wWGSVnN79Ns KNLw== X-Gm-Message-State: AOAM533KxFMA7/Ki4h5G1CpuHetsAXvwx3AkFVlVJp7gebXxZL1TnK0H weENWsaHVGM7V2gFxWJfunV87gkXq4O4KZ7Tc+gDbtcfGzFInQ== X-Google-Smtp-Source: ABdhPJzM2tlmpgRODK44yYBFyXI4Rq0AgBqrul5f04CE0dByDOll76iE6e/pUgC4aRLkIQM0KaFyItOhjz45sM8E1GE= X-Received: by 2002:a05:6602:214b:: with SMTP id y11mr28266373ioy.78.1607891011606; Sun, 13 Dec 2020 12:23:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sun, 13 Dec 2020 21:23:19 +0100 Message-ID: To: Jim Willeke Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000959dd905b65e4c14" Archived-At: Subject: Re: [GNAP] physical person 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, 13 Dec 2020 20:23:34 -0000 --000000000000959dd905b65e4c14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Yes. For end user at least, we wanted to convey that it is a real person. The case is different for the RO, indeed here person would be enough I believe. Fabien Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke a =C3= =A9crit : > A natural person is usually implied to be a Human Being. > As in jurisprudence, fundamental human rights are implicitly granted only > to Natural Persons. > > A person or entity seems to be more appropriate. > > -- > -jim > Jim Willeke > > > On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault > wrote: > >> Hi, >> >> Wasn't thinking about that, but yes. >> Natural person would be good. I change it in the wiki. >> >> Thxs >> Fabien >> >> On Sun, Dec 13, 2020 at 7:07 PM Tom Jones >> wrote: >> >>> I dislike this. A robot can be a physical person. What's wrong with >>> natural person that others use? >>> Peace ..tom >>> -- >>> TXAuth mailing 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 > --000000000000959dd905b65e4c14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,

    Yes.=C2=A0

    For end user= at least, we wanted to convey that it is a real person.=C2=A0

    The case is different for the RO, in= deed here person would be enough I believe.=C2=A0
    Fabien


    Le dim. 13 d=C3=A9c. 2020 = =C3=A0 21:20, Jim Willeke <jim@willek= e.com> a =C3=A9crit=C2=A0:
    <= div dir=3D"ltr">A natural person is usually implied to be a Human Being.As in jurisprudence, fundamenta= l human rights are implicitly granted only to Natural Persons.
    =

    A person or entity seems to be more appropriate.=

    --
    -jim
    Jim Willeke
    =


    On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault <f= abien.imbault@gmail.com> wrote:
    Hi,=C2=A0

    Wasn&#= 39;t thinking=C2=A0about that, but yes.
    Natural person would be g= ood. I change it in the wiki.=C2=A0

    Thxs
    Fabien

    On Sun, Dec 13, 2020 at 7:07 PM Tom Jones <thomas= clinganjones@gmail.com> wrote:
    I dislike this. A robot can be a physical person. What's wrong = with natural person that others use?
    Peace ..tom
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --000000000000959dd905b65e4c14-- From nobody Sun Dec 13 12:42:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9F83A091C for ; Sun, 13 Dec 2020 12:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVmZI1Diveta for ; Sun, 13 Dec 2020 12:42:02 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BAF3A0B0A for ; Sun, 13 Dec 2020 12:41:58 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id 190so1749899wmz.0 for ; Sun, 13 Dec 2020 12:41:58 -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=k0mds3PznJvWIOM3p9FOw3pLpYtHXV0ak64l2OgHM/s=; b=GhKgU0Azj74XMIGe5UbZDa7amXzp7fFISyTJmr5SyuUBWrK7N9U5n4vRui9S43SA9t 5zipbIIQzlFdYGdvdKHH5wMxk9/50VMQhmz63mO+F+kLgvIxgv2yqKvtB58pwODUE8Q1 e8hrRf/qn1Px6vY49EL31pYudwZPiERsAV/Gx/bD0WI1EDOEFl9HA9fOhB6J4lkdxV4B VBNmDTieXvo921wIme1bxXoEjARMl6gF9NrMPgS7QHZCmG2HamVuku0b126ptziHbdwn UBUqSs3nC9SS4DWUy6GvQBn5N19ZziN+OaNIKUyfzMzCsy5ZBUa8Wrp/MpBCKOtGPpXn VBZQ== 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=k0mds3PznJvWIOM3p9FOw3pLpYtHXV0ak64l2OgHM/s=; b=pIm5iDNj20W/QBoBebHEAXpeUe4aL0jXwfUctQJIAlTP6GUy9AYt0CObTVsGFbPpBm +jZW3TGKXlirueVpU7LxCVrH6xexBXSEPhvqr2u+GCyfGFbMWR/4hlZBUU/7G+O/azrn D7AKyVhW0Yc1XMD1U9xIUBYYhzs4y9uD/8pYvd9nP7jtUX+epi01L2TO6xhD1foQmwvU 1fg2Rjbk17hFzOhh+tyvAjO5zKytEIfzDbysnzIZg6MmmeeKS8GeIM7K0oCKpgymzh35 3RMzzadAKLwPsctn/U4uB6eCfAo+r23WKY4HMN8pmsP+ihXpBg7bSHONEytaJItSIJGr akDw== X-Gm-Message-State: AOAM533KiGazl/7hfPwx+sXvtW4x92YHYQDb2XoIt+sDsDDZ42Gk/joy RyQsiqb3jU5VlBOiqg6JI+4= X-Google-Smtp-Source: ABdhPJxemPiNxh0x5akbcN/J7kOJrwWXgubjzcwcxN9xwA84VKelTR6874FCo6xdJ0q6YeaL7MPlHA== X-Received: by 2002:a05:600c:410d:: with SMTP id j13mr24639364wmi.95.1607892116499; Sun, 13 Dec 2020 12:41:56 -0800 (PST) Received: from [192.168.68.107] (bzq-79-178-108-177.red.bezeqint.net. [79.178.108.177]) by smtp.gmail.com with ESMTPSA id a18sm27866680wrr.20.2020.12.13.12.41.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Dec 2020 12:41:55 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Sun, 13 Dec 2020 22:41:53 +0200 From: Yaron Sheffer To: Fabien Imbault CC: Denis , GNAP Mailing List Message-ID: <09FFCB7E-5BDF-4CB3-8504-65AAC2E81BBF@gmail.com> Thread-Topic: [GNAP] Terminology proposal References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> <13422918-A279-45FD-97B7-E02D74534960@gmail.com> <4B381A4C-573A-41E0-BD9E-6B97187ED2D5@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3690744114_2112126014" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 20:42:07 -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_3690744114_2112126014 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Agreed. =20 From: Fabien Imbault Date: Sunday, December 13, 2020 at 21:28 To: Yaron Sheffer Cc: Denis , GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Ok but if we limit to protected resources, we don't have that problem, so t= ypically is not needed. =20 On Sun, Dec 13, 2020 at 8:26 PM Yaron Sheffer wrote= : Hi Fabien, =20 =E2=80=9CTypically=E2=80=9D means =E2=80=9Cusually, though there may be fully public resource= s where some operations don=E2=80=99t require any authorization, but I don=E2=80=99t wan= t a normative statement in the Terminology section=E2=80=A6=E2=80=9D =20 Thanks, Yaron =20 From: Fabien Imbault Date: Sunday, December 13, 2020 at 21:21 To: Yaron Sheffer Cc: Denis , GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hi Yaron,=20 =20 Stylistic comments are very important too. And at some point we'll need a r= eview from native english speakers in the group (I'm sure Justin and Aaron w= ill be of great help here). =20 Just wondering: what do you mean by "typically"? (ideally I'd rather have a= definition which is not dependent on use case). =20 As soon as we land on something, I'll update the wiki. =20 Fabien =20 =20 =20 On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer wrote= : It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9Cserver that de= nies operations=E2=80=9D) a bit funny. How about: =20 Resource Server (RS) Definition: server that provides operations on protected resources; such op= erations typically require that the client provide valid access tokens issue= d by an AS Thanks, Yaron =20 From: Fabien Imbault Date: Sunday, December 13, 2020 at 13:20 To: Yaron Sheffer Cc: Denis , GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hello everyone,=20 =20 We're at the end of the 2 week period, and so I integrated the various feed= backs :=20 =20 a) from Yaron's feedback, removed new term "IS" and update issue https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle the proposal h= ere=20 b) integrated Tom's feedback regarding the RO (and moved to access token) c) definitions follow an ISO style as suggested by Denis, which we took as = a starting point (but I made the modifications I felt were necessary) =20 I modified the definitions, notes and examples as a consequence. You'll als= o find a summary of discussions for each term, so that we can keep track of = them too. =20 My biggest question is : what should we use as our main vocabulary between = privilege/rights/attribute? I tried to clarify, please let me know what you = think. The general idea is that we grant privileges that are delivered under= the form of access tokens (which contain rights and/or attributes). Regarding whether access tokens should be opaque or not, I suggest to remov= e that from the definition and handle that in issue https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/145 =20 All has been consolidated on the wiki too https://github.com/ietf-wg-gnap/g= nap-core-protocol/wiki/Terminology so that we have a clearer view of where w= e stand.=20 =20 Please comment further on the list if you have comments, I'll update if nec= essary (and refer to the mailing list url in the comment of the wiki update,= from now on). Then editors will review the proposal.=20 Here is a copy of https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/T= erminology#latest-discussion-update. =20 Latest discussion update Here we consolidate the latest proposal(s) from the group. We also include = the discussion items (individual feedbacks). Authorization Server (AS) Definition: server that grants privileges to a particular end-user and that= provides them to a client in the form of an access token Feedbacks / discussion / questions : Suggested "privilege" definition (that we would probably add as an addition= al sub-entry): "A privilege is the right to perform an operation (or action)= on a Resource." See also other def Note that we don't include claims in the definition (cf OIDC/SSI integratio= n), but since we talk about a "particular end-user" it is assumed somehow Denis suggested we used "rights and attributes" instead of privileges. [FI]= However i don't think one can really speak about granting attributes, excep= t indirectly (ABAC). See access token for more on that, where we can be more= specific. Do we allow cases such as distributing the AS on a mobile? (in this case we= 're at the limit of what we call a server) Client Definition: application used by an end-user to interact with an AS or a RS Note: this specification differentiates between a specific instance (the cl= ient instance, identified by its public key) and the software running the in= stance (the client software). For some kinds of client software, there could= be many instances of a single piece of client software. Example: a client can be a mobile application, a web application, etc. Feedbacks / discussion : Replaces previously proposed RC, we wouldn't provide a short name. Keep OAuth2 term, but we clarify it Further discussion on Client instance Resource Server (RS) Definition: server that denies operations on protected resources, unless th= e client provides valid access tokens issued by an AS Feedbacks / discussion : Denis suggests to make explicit that we could have several ASs - "issued by= one or more ASs" (also we'd need a convention on how to denote plural, e.g.= ASs). Not exactly sure right now of the multiple issuance would work, so ne= eds to be clarified. Also not sure if that's even necessary (do we lack in g= enerality if we keep the singular?) Resource Owner (RO) Definition: physical person acting on its own or representing an organizati= on, that may grant privileges on resources he has authority upon Note: the act of granting privileges may be manual (i.e. through an interac= tion) or automatic (i.e. through predefined rules). Feedbacks / discussion As some point we suggested "The RO may decide to remove its consent at any = time." Tom provided useful feedback on that. Moved to access token where it = fits more naturally. End-user Definition: physical person that operates with the client software Note: that physical person may or may not be the same entity as the RO Access token Definition: digitally signed data that contains specific rights and/or attr= ibutes Note 1: the access token can be issued to an end-user (usually requiring hi= s authentication) and subsequently refreshed. The AS usually provides a meth= od for the RO to revoke the privileges at any point in time. Note 2: an access token may act as a capability (i.e. bearer token) or requ= ire an additional authentication by binding to a key (i.e. bound token) Feedbacks / discussion Would require the subdefinitions right: ability for an end-user to perform = a given operation (or action) on a resource (or object) under the control of= a RS / attribute: property related to an end-user. Note 2 is here in relationship with PR 129 Grant Definition (verb): to permit, as a privilege given to an end-user to exerci= se some rights and/or assert attributes during a specific duration Definition (noun): the act of granting Key Definition: public cryptographic binding a request to the holder of a priva= te key, used by the protocol entities (AS, RS, client instance, bound token,= etc.) to identify themselves. Note: a key can be rotated or revoked by its holder. The protocol supports = the update of the key information. Feedbacks / discussion Denis thinks the term "key" is well understood and doesn't need to be defin= ed. Yet, I tend to believe we'd gain to keep it. First the generic term "key= " may be many things : symmetric/asymmetric, public/private, etc. It's also = useful to explain its use in the protocol Resource Definition: protected API served by a RS and accessed by a client, if and o= nly if a valid access token is provided =20 On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault w= rote: Hi Yaron,=20 =20 Yes I highlighted that this was a new term. We can deal with it as a separa= te issue indeed.=20 =20 Best Fabien =20 On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer wrote= : Hi Fabien, =20 Yes, we definitely need to reach closure on terminology, thank you for driv= ing this discussion! =20 One process comment: unless I=E2=80=99m missing something, the Interact (or Inter= action) Server is not mentioned in the current draft. I suggest we do not in= troduce new functional components or new behaviors as part of the terminolog= y discussion. Specifically, if the IS is useful, let=E2=80=99s reach consensus on = that separately. Then we can add it into the Terminology section. =20 Thanks, Yaron =20 From: TXAuth on behalf of Fabien Imbault Date: Friday, December 11, 2020 at 14:31 To: Denis Cc: GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hi Denis,=20 =20 Thanks for your detailed feedback. My comments are embedded into your messa= ge. Again those comments are my own, and we'll need to converge to some cons= ensus beyond what I say here. My main open question is really about the RO b= eing optional. Could you explain? =20 Fabien=20 =20 On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: This is a global response to the definitions proposal.=20 =20 Terminology I propose to adopt the way ISO defines how to write the definitions. It is a single sentence that may be substituted to the wording being define= d in the context of a sentence that uses that definition.=20 Since this single sentence can be substituted to the wording, there is not = point at the end of that sentence. The sentence does not=20 have a "a" or "the" in front of it. =20 [FI] In the first version, I was mostly trying to not get too far away from= the current text. But yes that's a good idea, it gives a more formal rule, = which has been proven to work.=20 =20 If more information is useful to understand the wording, it is placed in on= e or more notes afterwards. =20 Note: The ISO rules for drafting definitions are in the ISO/IEC Directives,= Part 2 (edition 2018): 16.5.6 Definitions The definition shall be written in such a form that it can replace the term= in its context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor= end with a full stop.=20 A definition shall not take the form of, or contain, a requirement. Only one definition per terminological entry is allowed. If a term is used = to define more than one concept, a separate terminological entry shall be cr= eated=20 for each concept and the domain shall be included in angle brackets before = the definition. Circular definitions, which repeat the term being defined, are not allowed. Comments are inserted between the lines. =20 Hello everyone, =20 =20 As an editor : a quick reminder that terminology issues will be discussed i= n the coming weeks, and we're expecting your inputs right now (according to = the process previously sent on the mailing list). https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology=20 =20 The rest of this message is a proposal written in my own name, and doesn't = involve discussions with the editors/chairs who might have different opinion= s. =20 Authorization Server (AS) Manages the granting of privileges to a third-party client instance. If the= RO consents to at least a part of what is requested, the AS issues an acces= s token to the client.=20 My questions:=20 - was else do we issue? (e.g. id claims, payment info, etc.) We could have = more than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I remo= ved that for now. - there might potentially be several AS, currently we don=E2=80=99t reflect that = anywhere. If would leave that as an open item, depending on what we end up d= oing in the spec I am not in favour of this definition: A RO as defined later: "authorizes t= he request to access a protected resource from the RS to the client".=20 This does not mean in any way that a RO has necessarily a direct relationsh= ip with one or more ASs. [FI] indeed we could remove that limitation, to hav= e a more general definition Using the ISO style for definitions, I propose: Authorization Server (AS): server that grants rights and/or attributes to a= particular end-user and that provides them to a client in the form of an ac= cess token Since this definition is using the words "rights" and "attributes", these t= wo terms need to be defined as well. right: ability for an end-user to perform a given operation on an object un= der the control of a RS attribute: property related to an end-user =20 [FI] I like your proposal in general. There might be some discussions on th= e details. I don't think it makes sense to grant "attributes". =20 Some explanations: a "right" is able to support a capability scheme. An "at= tribute" is able to support an ACL scheme.=20 These two schemes are able to support "discretionary access control" where = the end-user has a "need-to-know".=20 However, some attributes are also able to support what was called in the p= ast "mandatory access control"; for example,=20 if the end-user is cleared to "top-secret / marketing strategy". =20 Interact Server (IS) - this is a new proposed term Manages the front-end interaction with the RO, in order to gather its conse= nt. Depending on the deployment model and the privacy requirements,=20 the IS may be a component of the AS, or may be distinct and managed by anot= her party. Example : an IS usually involves a web interface accessed by RO through a w= eb browser.=20 Note : an IS is not always required, especially if the access is granted th= rough automated policies. Using the ISO style for definitions, I propose: =20 Interaction Server (IS)=20 component from the AS or server interfacing with an AS that manages the int= eractions with a RO, in order to gather its authorization Note : since the RO is an optional component, the IS is also an optional co= mponent. =20 [FI] indeed IS is optional. note for myself when looking at RO : why is RO = optional ? =20 Client=20 Requests privileges from the AS, and uses access tokens at the RS. This spe= cification differentiates between a specific instance (the client instance, = identified by its unique public key)=20 and the software running the instance (the client software). . For some kin= ds of client software, there could be many instances of a single piece of cl= ient software. The AS determines which policies apply to a given client instance, includin= g what it can request and on whose behalf. Some comments: The above text is stating: "(the client instance, identified= by its unique public key)".=20 A client instance may use a public key, but that key is not necessarily uni= que, in particular when there are multiple ASs. [FI] yes, although when possible I would still consider a better practice t= o expose a key to a specific AS and not to the entire set of available ASs.=20 Example : a client can be a mobile application or a web application (the cl= ient software) that requires authorizations from the RO to retrieve content = from various protected APIs. The client instance may for instance refer to a= specific version of that client software. See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protoco= l/pull/132 (client instance).=20 Using the ISO style for definitions, I propose: Client: application used by an end-user to interact with an AS or a RS Note: a client can be a mobile application or a web application [FI] for me= those are just examples, because there could me more (ex IoT device) [FI] you remove the entire discussion on client instance / client software,= is that on purpose because you think it's not useful/right, or is it becaus= e of something else? (maybe add your comment of the related issue) =20 Resource Server (RS) Accepts valid access tokens from the client issued by the AS and serves pro= tected resources on behalf of the RO. There could be multiple RSs protected = by the AS that the client may call. Example : a RS is often composed of protected APIs that can be consumed by = authorized client software. =20 One comment: a RO is not necessarily involved. [FI] a bit hard to imagine, = there's some kind of owner. Could you be more explicit? Using the ISO style for definitions, I propose: Resource Server (RS): server that accepts valid access tokens from clients = issued by one or more ASs which are used to grant or deny some requested ope= rations Note: a RS is often composed of protected APIs that can be consumed by clie= nts. =20 Resource Owner (RO) Authorizes the request to access a protected resource from the RS to the cl= ient. The RO may decide to remove its consent at any time. Note : the RO may be a physical person or may represent an organization. =20 Two comments: In order to avoid confusion with the end-user consent, the wo= rd " authorization" is being used instead of "consent". [FI] ok=20 It should be said that the RO is an optional component. [FI] why? Using the= ISO style for definitions, I propose: Resource Owner (RO): physical person acting on its own or representing an o= rganization that authorizes to clients operations on protected resources fro= m a RS Note: The RO is an optional component that may interact either with one RS = or with one or more ASs ,e.g. using an IS. End-user =E2=80=93 this was previously Requesting Party RQ A physical person that operates and interacts with the client software.=20 Note : the end-user may or may not be the same entity as the RO.=20 The Note is slightly incorrect. the physical person may or may not be the s= ame entity as the RO. [FI] I didn't understand your comment Using the ISO style for definitions, I propose: End-user : physical person that operates and interacts with the client sof= tware=20 Note : that physical person may or may not be the same entity as the RO.=20 =20 Access Token A set of privileges delegated to the client instance for a specific end-use= r. An access token is created by the AS, consumed and verified by the RS, an= d issued to and carried by the client's end-user on behalf of the RO. The co= ntents and format of the access token are opaque to the client. Example : JWT is a commonly used format.=20 Note 1 : an access token generally has a limited duration, after which it m= ay be refreshed at a regular interval. Note 2 : an access token may be revoked at any time by the RO.=20 Note 3 : an access token may act as a capability or require an additional a= uthentication by binding to a key=20 A fundamental point: the third sentence from the definition states: "The co= ntents and format of the access token are opaque to the client". [FI] I'll check your other thread dedicated to that issue=20 See my other email sent today about "RS-Token Introspection or RC-Token Int= rospection" where I conclude: For end-users caring about their privacy (or for systems willing to p= rotect the user's privacy), access tokens should not be considered to be opaque to RCs nor to RSs and ASs should not support Token Intro= spection, whether it is RS-Token Introspection or RC-Token Introspection. The example and the other Notes above should be removed. If needed they sho= uld be placed in the main body of the document. Using the ISO style for definitions, I propose:=20 Access Token : digitally signed data issued by an Authorization Server (AS)= and consumed by a Resource Server (RS)=20 that contains rights and/or attributes granted to = a particular end-user =20 Grant The process by which the client requests and is given delegated access to t= he RS by the AS through the authority of the RO. Using the ISO style for definitions, I propose: Grant: permission given to end-user to use a subset of his rights and/or hi= s attributes at a specific time and for a specific duration =20 Key A public cryptographic binding a request to the holder of a private key. Ac= cess tokens and client instances can be associated with specific keys at a p= oint in time.=20 Note : a key can be rotated or revoked by its holder. The protocol supports= the update of the key information.=20 "key" is a general term that is well understood and that does not need to b= e defined. [FI] I really wouldn't bet on that. We can reuse an existing defi= nition but it is a central piece so we need to be explicit The "definitions" section is not intended to explain what can be done with = the term that is being defined. [FI] ok we can work on that Until the word "key" is qualified using one or more other terms, this defin= ition should be removed. =20 Resource A protected API served by the RS and accessed by the client if and only if = access has been granted. Access to this resource is delegated by the RO as p= art of the grant process. The second sentence of the definition is not in accordance with the ISO sty= le or definitions and furthermore this second sentence should be removed sin= ce a RO is an optional element. =20 Using the ISO style for definitions, I propose:=20 Resource: protected API served by a RS and accessed by a client, if and onl= y if access is granted by an access token=20 Subject Information Information about a subject (usually a RO) that is returned directly to the= client from the AS. Note : this information needs to be unique.=20 =20 This definition exhibits several problems:=20 (1) The term "subject" is not defined.=20 (2) The information that is returned is for an end-user, i.e. not for "(usu= ally a RO)".=20 (3) The Note states : "this information needs to be unique". Does it mean u= nique for the AS ? globally unique ?=20 This definition should be revisited. [FI] I agree (I myself had many questi= ons here) Denis =20 My questions :=20 - probably we=E2=80=99d need to define subject Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697= /Subject+Dictionary+Entry - might be useful to clarify the relationship to what identity providers do= =20 =20 =20 Cheers Fabien =20 =20 =20 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3690744114_2112126014 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    Agreed.

     

    From: Fabien Imbault <fabien.imbault@gmail.com>
    Da= te: Sunday, December 13, 2020 at 21:28
    To: Yaron Sheffer <y= aronf.ietf@gmail.com>
    Cc: Denis <denis.ietf@free.fr>, GNA= P Mailing List <txauth@ietf.org>
    Subject: Re: [GNAP] Termino= logy proposal

     =

    Ok but if we limit to protected reso= urces, we don't have that problem, so typically is not needed.

     

    Hi Fabien,=

     

    =E2=80=9CTypically=E2=80=9D means =E2=80=9Cusually, though there = may be fully public resources where some operations don=E2=80=99t require any auth= orization, but I don=E2=80=99t want a normative statement in the Terminology secti= on=E2=80=A6=E2=80=9D

     

    Thanks,

    &nbs= p;            &n= bsp;  Yaron

     

    From: Fabien Imbault <fabien.imbault@gmail.com>
    Date: Sunday, De= cember 13, 2020 at 21:21
    To: Yaron Sheffer <yaronf.ietf@gmail.com>
    Cc: = Denis <denis.ietf= @free.fr>, GNAP Mailing List <txauth@ietf.org>
    Subject: Re: [GNAP] Terminolo= gy proposal

     

    Hi Yaron, 

     

    Stylistic comments are very important too. And at some point we'll need = a review from native english speakers in the group (I'm sure Justin and= Aaron will be of great help here).

     

    Just wondering: what do you mean by "typicall= y"? (ideally I'd rather have a definition which is not dependent on use= case).

     

    As soon= as we land on something, I'll update the wiki.

    &= nbsp;

    Fabien

     

     

     

    On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:

    It=E2=80=99s purely stylistic, bu= t I find the definition of RS (=E2=80=9Cserver that denies operations=E2=80=9D) a bit fu= nny. How about:

     

    Reso= urce Server (RS)

    • Definition: server that provides operations on = protected resources; such operations typically require that the client provi= de valid access tokens issued by an AS

    Thanks,<= o:p>

              =       Yaron

     

    From: Fabien Imbault <fabien.imbault@gmail.com>
    = Date: Sunday, December 13, 2020 at 13:20
    To: Yaron Sheffer <= ;yaronf.ietf@gmail.co= m>
    Cc: Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org>
    Subject: = Re: [GNAP] Terminology proposal

     

    Hello everyone, 

     

    We're at the end of the 2 week period, and so I int= egrated the various feedbacks : 

     =

    a) from Yaron's feedback, removed new term "IS&q= uot; and update issue https://github.com/ietf-wg-gnap/gnap-= core-protocol/issues/133 to handle the proposal here 

    b) integrated Tom's feedback regarding the RO (and moved = to access token)

    c) definitions follow an ISO st= yle as suggested by Denis, which we took as a starting point (but I made the=  modifications I felt were necessary)

     =

    I modified the definitions, notes and examples a= s a consequence. You'll also find a summary of discussions for each term, so= that we can keep track of them too.

     <= /o:p>

    My biggest question is : what should we use as our mai= n vocabulary between privilege/rights/attribute? I tried to clarify, please = let me know what you think. The general idea is that we grant privileges tha= t are delivered under the form of access tokens (which contain rights and/or= attributes).

    Regarding whether access tokens sho= uld be opaque or not, I suggest to remove that from the definition and handl= e that in issue https://github.com/ietf-wg-gnap/gnap-core-p= rotocol/issues/145

     

    All has been consolidated on the wiki too htt= ps://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so that= we have a clearer view of where we stand. 

    =  

    Please comment further on the list if you = have comments, I'll update if necessary (and refer to the mailing list = url in the comment of the wiki update, from now on). Then editors will revie= w the proposal. 

    Here is a copy of https://github.com/ietf-wg-gnap/gnap-= core-protocol/wiki/Terminology#latest-discussion-update.

    <= /div>

     

    Latest discussion update

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

    Authoriza= tion Server (AS)

    • Definition: server that grants privileges to a= particular end-user and that provides them to a client in the form of an ac= cess token

    Feedbacks / discussion / questions :
    • Sugges= ted "privilege" definition (that we would probably add as an addit= ional sub-entry): "A privilege is the right to perform an operation (or= action) on a Resource." See also other def
    • Note that we don't include claims in the definition (cf OID= C/SSI integration), but since we talk about a "particular end-user"= ; it is assumed somehow
    • Denis suggested we used "rights and attributes" in= stead of privileges. [FI] However i don't think one can really speak about g= ranting attributes, except indirectly (ABAC). See access token for more on t= hat, where we can be more specific.
    • Do we allow cases such as distributing the AS on= a mobile? (in this case we're at the limit of what we call a server)=

    = Client<= o:p>

    • Definition: application used by an end-user to interact with an AS or a= RS
    • Note:= this specification differentiates between a specific instance (the client i= nstance, identified by its public key) and the software running the instance= (the client software). For some kinds of client software, there could be ma= ny instances of a single piece of client software.
      • Example: a client can be a mobile = application, a web application, etc.

    Feedbacks / discussion :

    • Replaces previously proposed RC, we wouldn't provide a short name.
    • = Keep OAuth2= term, but we clarify it
    • Further discussion on Client instance

    Resource Se= rver (RS)

    • Definition: server that denies operations on protected= resources, unless the client provides valid access tokens issued by an AS

    Feedbacks / discussion :

    • Denis suggests to make explicit= that we could have several ASs - "issued by one or more ASs" (als= o we'd need a convention on how to denote plural, e.g. ASs). Not exactly sur= e right now of the multiple issuance would work, so needs to be clarified. A= lso not sure if that's even necessary (do we lack in generality if we keep t= he singular?)

    Resource Owner (RO)

    • Definition: physical person acting on= its own or representing an organization, that may grant privileges on resou= rces he has authority upon
    • Note: the act of granting privileges may be manual (i.e. = through an interaction) or automatic (i.e. through predefined rules).=

    = Feedbacks / discussion

    • As some point we suggested "The R= O may decide to remove its consent at any time." Tom provided useful feedback on that. Moved to access token = where it fits more naturally.

    End-user

    • Definition: physical person tha= t operates with the client software
    • Note: that physical person may or may not be th= e same entity as the RO

    Access token

    • Definition: digitally signed data= that contains specific rights and/or attributes
    • Note 1: the access token can be is= sued to an end-user (usually requiring his authentication) and subsequently = refreshed. The AS usually provides a method for the RO to revoke the privile= ges at any point in time.
    • Note 2: an access token may act as a capability (i.e. bea= rer token) or require an additional authentication by binding to a key (i.e.= bound token)

    Feedbacks / discussion

    • Would require th= e subdefinitions right: ability for an end-user to perform a given operation= (or action) on a resource (or object) under the control of a RS / attribute= : property related to an end-user.
    • Note 2 is here in relationship with PR 129

    Grant

    • Definition (verb): to permit, as a privilege given = to an end-user to exercise some rights and/or assert attributes during a spe= cific duration
    • Definition (noun): the act of granting
    Key
    • Definition: public cr= yptographic binding a request to the holder of a private key, used by the pr= otocol entities (AS, RS, client instance, bound token, etc.) to identify the= mselves.
    • Note: a key can be rotated or revoked by its holder. The protocol supports = the update of the key information.

    Feedbacks / discussion

    • Denis thinks the term "key" is well understood and doesn't nee= d to be defined. Yet, I tend to believe we'd gain to keep it. First the gene= ric term "key" may be many things : symmetric/asymmetric, public/p= rivate, etc. It's also useful to explain its use in the protocol=

    Resource

    • Definition: protected API served by a RS and accessed by a client, if and= only if a valid access token is provided
    <= /div>

     

    On Fri, Dec 11, 2020 at 6:05 PM Fabi= en Imbault <fab= ien.imbault@gmail.com> wrote:

    Hi= Yaron, 

     

    Yes I h= ighlighted that this was a new term. We can deal with it as a separate issue= indeed. 

     

    = Best

    Fabien

     

    On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,

     

    Yes, we definitely need to reach closure on te= rminology, thank you for driving this discussion!

     

    One process comment: unless I=E2=80=99m missing something, the Intera= ct (or Interaction) Server is not mentioned in the current draft. I suggest = we do not introduce new functional components or new behaviors as part of th= e terminology discussion. Specifically, if the IS is useful, let=E2=80=99s reach c= onsensus on that separately. Then we can add it into the Terminology section= .

     

    Thanks,

      = ;            &nb= sp; Yaron

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com&= gt;
    Date: Friday, December 11, 2020 at 14:31
    To: Denis &= lt;denis.ietf@free.fr>
    Cc: GNAP Mailing List <    txauth@ietf.org>
    Subject: Re: [GNAP] Termino= logy proposal

     

    <= div>

    Hi Denis, 

     

    <= div>

    Thanks for your detailed feedback. My comments are embedded into your = message. Again those comments are my own, and we'll need to converge to some= consensus beyond what I say here. My main open question is really about the= RO being optional. Could you explain?

     

    Fabien 

     =

    On Fri, Dec 11, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:

    This is a global response to the de= finitions proposal.

     

    <= div>

    Terminology

    I propose to adopt the way ISO defi= nes how to write the definitions.

    It is a single sentence that may be substituted to the wording being defined in the= context of a sentence that uses that definition.
    Since this single sent= ence can be substituted to the wording, there is not point at the end of tha= t sentence. The sentence does not
    have a "a" or "the"= ; in front of it.

    &nbs= p;

    [FI] In the first= version, I was mostly trying to not get too far away from the current text.=  But yes that's a good idea, it gives a more formal rule, which has been proven = to work. 

     

    If more information is useful to und= erstand the wording, it is placed in one or more notes afterwards.

     

    Note: The ISO rules for = drafting definitions are in the ISO/IEC Directives, Part 2 (edition 2018):

    16.5.6    Definitions

    The definition shall b= e written in such a form that it can replace the term in its context. It sha= ll not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end with a full stop. =
    A definition shall not take the form of, or contain, a requirement.
    <= br>Only one definition per terminological entry is allowed. If a term is use= d to define more than one concept, a separate terminological entry shall be = created
    for each concept and the domain shall be included in angle brack= ets before the definition.

    Circular definitions, which repeat the ter= m being defined, are not allowed.

    Comments are inserted between the= lines.

     

    Hello everyone,&nbs= p;

     

    As an editor : a = quick reminder that terminology issues will be discussed in the coming = weeks, and we're expecting your inputs right now (according to the process p= reviously sent on the mailing list).

     

    The rest of this message is a proposal written in my own= name, and doesn't involve discussions with the editors/chairs who might hav= e different opinions. 

    Authorization Server (AS)

    Manages the granting of p= rivileges to a third-party client instance. If the RO consents to at least a= part of what is requested, the AS issues an access token to the client.

    My questions: =

    - was else do we issu= e? (e.g. id claims, payment info, etc.) We could have more than access token= s, but =E2=80=9Cdirected information=E2=80=9D is not clear. I removed that for now.

    - there might poten= tially be several AS, currently we don=E2=80=99t reflect that anywhere. If would l= eave that as an open item, depending on what we end up doing in the spec

    = I am not in favou= r of this definition: A RO as defined later: "authorizes the request to= access a protected resource from the RS to the client".
    This does = not mean in any way that a RO has necessarily a direct relationship with one= or more ASs.     = [FI] indeed we could remove that limitation, to have a more general definiti= on

    Using the ISO sty= le for definitions, I propose:

    Authorization Server (AS): ser= ver that grants rights and/or attributes to a particular end-user and that p= rovides them to a client in the form of an access token

    Since this definition is using the words "rights" and "attributes", these two terms need to = be defined as well.

    right: ability for an end-user to perform a given= operation on an object under the control of a RS

    attribu= te: property related to an end-user

    =

     

    [FI] I like your proposal in general. There might be some discussions on t= he details. I don't think it makes sense to grant "attributes".&nb= sp;  

    Some explanations: a= "right" is able to support a capability scheme. An "attribut= e" is able to support an ACL scheme.

    These two sche= mes are able to support "discretionary access control" where the e= nd-user has a "need-to-know".

    However, some at= tributes are also able to support what  was called in the past "ma= ndatory access control"; for example,

    if the end-us= er is cleared to "top-secret / marketing strategy".

     

    Interact Server (IS) - this is a new proposed term<= /o:p>

    Manages the front-end interaction wi= th the RO, in order to gather its consent. Depending on the deployment model= and the privacy requirements,
    the IS may be a component of the AS, or m= ay be distinct and managed by another party.

    Example : an IS usually involves a web interface accesse= d by RO through a web browser.

    Note : an IS is not always required, especially if the access is gran= ted through automated policies.

    Using the ISO style for definitions, I propose:=

     

    Interaction Server (= IS)

    component from the AS or server interfacing with an AS that mana= ges the interactions with a RO, in order to gather its authorization    <= o:p>

    Note : since the RO is an = optional component, the IS is also an optional component.<= /h3>

     

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >[FI] indeed IS is optional. note for myself when lo= oking at RO : why is RO optional ?  

    <= div>

    Clie= nt

    Requests privileges from the AS, and uses access tokens at the RS. This = specification differentiates between a specific instance (the client instanc= e, identified by its unique public key)
    and the software running the ins= tance (the client software). . For some kinds of client software, there coul= d be many instances of a single piece of client software.
    The AS determin= es which policies apply to a given client instance, including what it can re= quest and on whose behalf.

    Some comments: The above text is stating: &= quot;(the client instance, identified by its uni= que public key)".
    A client instance may use a public key, but that = key is not necessarily unique, in particular when there are multiple ASs.

    [FI] yes, although when possible I would still consider a better practice t= o expose a key to a specific AS and not to the entire set of available ASs.&= nbsp;

    Exam= ple : a client can be a mobile application or a web application (the client = software) that requires authorizations from the RO to retrieve content from = various protected APIs. The client instance may for instance refer to a spec= ific version of that client software.

    See on-going discussion : https://github.com/ietf-wg-gnap/gnap-c= ore-protocol/pull/132 (client instance).

    Using the ISO style f= or definitions, I propose:

    Client: app= lication used by an end-user to interact with an AS or a RS

    =

    Note: a client can be a mobile application or a web application = [FI] for me th= ose are just examples, because there could me more (ex IoT device)

    [= FI] you remove the entire discussion on client instance / client software, i= s that on purpose because you think it's not useful/right, or is it because = of something else? (maybe add your comment of the related issue)   = ;

    Resource Server (RS)

    Accepts valid access tokens from the client issue= d by the AS and serves protected resources on behalf of the RO. There could = be multiple RSs protected by the AS that the client may call.

    Example : a RS is often composed of = protected APIs that can be consumed by authorized client software. 

    One comment: a RO is= not necessarily involved. [FI] a bit hard to imagine, there's some kind of owner. Could y= ou be more explicit?

    Using the ISO style for definitions, I propose:

    Resource Ser= ver (RS): server that accepts valid access tokens from clients issued by one= or more ASs which are used to grant or deny some requested operations

    Note: a RS is often composed of protected APIs t= hat can be consumed by clients.

     

    Resource O= wner (RO)

    Authorizes = the request to access a protected resource from the RS to the client. The RO= may decide to remove its consent at any time.

    Note : the RO may be a physical person or may repre= sent an organization.

     =

    Two comments: In order to avoid confusion with th= e end-user consent, the word " authorization" is being used instea= d of "consent". [FI] ok 

    = It should be said= that the RO is an optional component. [FI] why? Using the ISO style for definitions, I propose:

    Resource Own= er (RO): physical person acting on its own or representing an organization t= hat authorizes to clients operations on protected resources from a RS=

    Note: The RO is an optional component that may in= teract either with one RS or with one or more ASs ,e.g. using an IS.<= o:p>

    End-user =E2=80=93 this was previously Requesting Party RQ

    A physical person that o= perates and interacts with the client software.

    Note : the end-user may or may not be the same en= tity as the RO.

    The Note is sli= ghtly incorrect. the physical person may or may not be the same entity as the RO. = [FI] I didn't understand your comment<= /span>

    Using the ISO style = for definitions, I propose:

    End-user :  physical person that operates and interacts with the cl= ient software

    Note : that physical pe= rson may or may not be the same entity as the RO. <= /p>

     

    Access Token

    A set of privileges delegated to the client instance for a sp= ecific end-user. An access token is created by the AS, consumed and verified= by the RS, and issued to and carried by the client's end-user on behalf of = the RO. The contents and format of the access token are opaque to the client= .

    Example : JWT is a c= ommonly used format.

    = Note 1 : an access token generally has a limited duration, after which it ma= y be refreshed at a regular interval.

    Note 2 : an access token may be revoked at any time by the R= O.

    <= span style=3D'font-family:"Arial",sans-serif'>Note 3 : an access token may act= as a capability or require an additional authentication by binding to a key=

    A fundamental point: the third= sentence from the definition states: "The = contents and format of the access token are opaque to the client".

    [F= I] I'll check your other thread dedicated to that issue 

    See my other email sent today about "RS-Token= Introspection or RC-Token Introspection" where I conclude:=

          For end-users caring about their priv= acy (or for systems willing to protect the user's privacy), access tokens sh= ould not be considered
          to be opaque to RCs nor to RSs and ASs shou= ld not support Token Introspection, whether it is RS-Token Introspection or = RC-Token Introspection.

    The example and the other Notes above should be removed. If= needed they should be placed in the main body of the document.<= /o:p>

    Usi= ng the ISO style for definitions, I propose:

    Access Token : digitally signed data iss= ued by an Authorization Server (AS) and consumed by a Resource Server (RS) <= br>            &= nbsp;            that= contains rights and/or attributes granted to a = particular end-user

     

    <= h3 style=3D'margin-bottom:12.25pt;line-height:125%'>Grant

    The process by which the= client requests and is given delegated access to the RS by the AS through t= he authority of the RO.

    Using the ISO style for definitions, I propose:=

    Grant: permission given to end-user to use a subset of his rights and/= or his attributes at a specific time and for a specific duration<= /p>

     

    <= span style=3D'font-size:10.0pt;line-height:125%;font-family:"Arial",sans-serif= ;color:#24292E'>Key

    A= public cryptographic binding a request to the holder of a private key. Acce= ss tokens and client instances can be associated with specific keys at a poi= nt in time.

    Note : a = key can be rotated or revoked by its holder. The protocol supports the updat= e of the key information.

    "key" is a general term that is well understood and that = does not need to be defined. [FI] I really wouldn't bet on that. We can reuse an existing = definition but it is a central piece so we need to be explicit

    The "definitions" section is not intended to e= xplain what can be done with the term that is being defined. [FI] ok we can work on that
    Until the word "key" is qualified using one or more other te= rms, this definition should be removed.

     <= /o:p>

    =

    Resource=

    A protected API serv= ed by the RS and accessed by the client if and only if access has been grant= ed. Access to this resource is delegated by the RO as part of the grant proc= ess.

    The second se= ntence of the definition is not in accordance with the ISO style or definiti= ons and furthermore this second sentence should be removed since a RO is an = optional element.

     

    Using the ISO style for definitions, I propose:

    Resource: protected API served by a RS and accessed= by a client, if and only if access is granted by an access token

    Subject Info= rmation

    = Information about= a subject (usually a RO) that is returned directly to the client from the A= S.

    Note : this information= needs to be unique.

     

    This defini= tion exhibits several problems:

    (1) The term "subject" is not def= ined.

    (2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

    = (3) The Note states : "this information needs to be unique". Does = it mean unique for the AS ? globally unique ?

    This definition should be revisited. [FI] I agree (I myself had many ques= tions here)

    Denis

     

    My que= stions :

    - probabl= y we=E2=80=99d need to define subject

    Subject : https://open= -measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Ent= ry

    - might be u= seful to clarify the relationship to what identity providers do =

     

     

    Cheers<= /p>

    Fabien

     

     

     

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

     

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

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

    <= /div> --B_3690744114_2112126014-- From nobody Sun Dec 13 12:47:55 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18A03A094E for ; Sun, 13 Dec 2020 12:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTye_F5Smxp1 for ; Sun, 13 Dec 2020 12:47:50 -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 031B03A0936 for ; Sun, 13 Dec 2020 12:47:49 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id n4so14943177iow.12 for ; Sun, 13 Dec 2020 12:47:49 -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=Mng3OXpyKGjL6QDXcmUH37vAunkkUkQH77ohZJ+v2hM=; b=gWX8p2f+0l1+o8QLhYDqjr7JjK332jL0kYfhlpy+q1r4KIa1y8ti00lGiAawcHaD92 RzqXnTcIWyvQo3RxQ+KCurrKfKKozpZs17PsNhHj/D0CCxz+ZFgptqt7ry2f44HpFDTu fFVonr8coFKczpEK/xLU326kiZMJ9tU0CNbOMtKq0rY6a7/kw5Z3A5SnuFwNeNKM4YWY qrBFplqPKm321QHaT1zR2OhzDC3LUpUZ6iGpdkohvZTiZSYOz/sk0nccVRARRyqP59Vw EXO1ZXpdStbNCVo6zYuc2eUlXfodhaxKWd8Bxy01u2Jl3nBAenaw49lyMnlQ5OSsl5Kk eYSQ== 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=Mng3OXpyKGjL6QDXcmUH37vAunkkUkQH77ohZJ+v2hM=; b=s76OIvliLX7s7grBFdOt8Accbv86z4MOL6xATYw4WZt/nLIR4mtS0nbkm9I6kTjRZf JlTqa3QCWRIcoxEhRfCbG9/szzwddEihKZ7zbIiW+b5a4yzE3kdfbnCSjDz8/49ursVS T+qUOhaRVhykFWuPzzrPf2JQyXfcExiaNVkJJftWfqULI7sELour/HvWnFdoS29q3rzf dQuOK9nsFFjrnrA4lLhXYFfMuqoSA2KtHM00HORy5Q5sC6GgIDeTjXnuXz0U021EHSTb WZuEUDd4y4fKd1BIpFqvCiiLQWVPWWfQuGxB1r3RGi7VpLduCoeqGE1S9lGNiDO2TYBu zF2g== X-Gm-Message-State: AOAM532JjZxW7E1ACXpAMAmsOyB6aelOS9DCk83xO6EZcnwSaEAlMWVn pgn65jbdgMnTM60OASgaSAzmrbv+Ebch8TEAoMw= X-Google-Smtp-Source: ABdhPJz5qVhrNQpFxWH7S2ynLSLnzx3do73b4G7haVUVCeawD+h4Mmlt448oKZTl0O+L5E7x8rZv+SbfvzB0fk4sShE= X-Received: by 2002:a6b:7a0c:: with SMTP id h12mr7746384iom.162.1607892469087; Sun, 13 Dec 2020 12:47:49 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> <13422918-A279-45FD-97B7-E02D74534960@gmail.com> <4B381A4C-573A-41E0-BD9E-6B97187ED2D5@gmail.com> <09FFCB7E-5BDF-4CB3-8504-65AAC2E81BBF@gmail.com> In-Reply-To: <09FFCB7E-5BDF-4CB3-8504-65AAC2E81BBF@gmail.com> From: Fabien Imbault Date: Sun, 13 Dec 2020 21:47:35 +0100 Message-ID: To: Yaron Sheffer Cc: Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000075021f05b65ea3e4" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 20:47:54 -0000 --00000000000075021f05b65ea3e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've updated the wiki with the latest remarks (except from Tom's comment on client, which needs further thought I think). Thanks Fabien Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:41, Yaron Sheffer a =C3=A9crit : > Agreed. > > > > *From: *Fabien Imbault > *Date: *Sunday, December 13, 2020 at 21:28 > *To: *Yaron Sheffer > *Cc: *Denis , GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Ok but if we limit to protected resources, we don't have that problem, so > typically is not needed. > > > > On Sun, Dec 13, 2020 at 8:26 PM Yaron Sheffer > wrote: > > Hi Fabien, > > > > =E2=80=9CTypically=E2=80=9D means =E2=80=9Cusually, though there may be f= ully public resources > where some operations don=E2=80=99t require any authorization, but I don= =E2=80=99t want a > normative statement in the Terminology section=E2=80=A6=E2=80=9D > > > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Sunday, December 13, 2020 at 21:21 > *To: *Yaron Sheffer > *Cc: *Denis , GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hi Yaron, > > > > Stylistic comments are very important too. And at some point we'll need a > review from native english speakers in the group (I'm sure Justin and Aar= on > will be of great help here). > > > > Just wondering: what do you mean by "typically"? (ideally I'd rather have > a definition which is not dependent on use case). > > > > As soon as we land on something, I'll update the wiki. > > > > Fabien > > > > > > > > On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer > wrote: > > It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9C= server that > denies operations=E2=80=9D) a bit funny. How about: > > > Resource Server (RS) > > - Definition: server that provides operations on protected resources; > such operations typically require that the client provide valid access > tokens issued by an AS > > Thanks, > > Yaron > > > > *From: *Fabien Imbault > *Date: *Sunday, December 13, 2020 at 13:20 > *To: *Yaron Sheffer > *Cc: *Denis , GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hello everyone, > > > > We're at the end of the 2 week period, and so I integrated the various > feedbacks : > > > > a) from Yaron's feedback, removed new term "IS" and update issue > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle > the proposal here > > b) integrated Tom's feedback regarding the RO (and moved to access token= ) > > c) definitions follow an ISO style as suggested by Denis, which we took a= s > a starting point (but I made the modifications I felt were necessary) > > > > I modified the definitions, notes and examples as a consequence. You'll > also find a summary of discussions for each term, so that we can keep tra= ck > of them too. > > > > My biggest question is : what should we use as our main vocabulary betwee= n > privilege/rights/attribute? I tried to clarify, please let me know what y= ou > think. The general idea is that we grant privileges that are delivered > under the form of access tokens (which contain rights and/or attributes). > > Regarding whether access tokens should be opaque or not, I suggest to > remove that from the definition and handle that in issue > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 > > > > All has been consolidated on the wiki too > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so > that we have a clearer view of where we stand. > > > > Please comment further on the list if you have comments, I'll update if > necessary (and refer to the mailing list url in the comment of the wiki > update, from now on). Then editors will review the proposal. > > Here is a copy of > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology#lates= t-discussion-update > . > > > Latest discussion update > > Here we consolidate the latest proposal(s) from the group. We also includ= e > the discussion items (individual feedbacks). > Authorization Server (AS) > > - Definition: server that grants privileges to a particular end-user > and that provides them to a client in the form of an access token > > Feedbacks / discussion / questions : > > - Suggested "privilege" definition (that we would probably add as an > additional sub-entry): "A privilege is the right to perform an operati= on > (or action) on a Resource." See also other def > > - Note that we don't include claims in the definition (cf OIDC/SSI > integration), but since we talk about a "particular end-user" it is as= sumed > somehow > - Denis suggested we used "rights and attributes" instead of > privileges. [FI] However i don't think one can really speak about gran= ting > attributes, except indirectly (ABAC). See access token for more on tha= t, > where we can be more specific. > - Do we allow cases such as distributing the AS on a mobile? (in this > case we're at the limit of what we call a server) > > Client > > - Definition: application used by an end-user to interact with an AS > or a RS > - Note: this specification differentiates between a specific instance > (the client instance, identified by its public key) and the software > running the instance (the client software). For some kinds of client > software, there could be many instances of a single piece of client > software. > - Example: a client can be a mobile application, a web application, > etc. > > Feedbacks / discussion : > > - Replaces previously proposed RC, we wouldn't provide a short name. > - Keep OAuth2 term, but we clarify it > - Further discussion on Client instance > > > Resource Server (RS) > > - Definition: server that denies operations on protected resources, > unless the client provides valid access tokens issued by an AS > > Feedbacks / discussion : > > - Denis suggests to make explicit that we could have several ASs - > "issued by one or more ASs" (also we'd need a convention on how to den= ote > plural, e.g. ASs). Not exactly sure right now of the multiple issuance > would work, so needs to be clarified. Also not sure if that's even > necessary (do we lack in generality if we keep the singular?) > > Resource Owner (RO) > > - Definition: physical person acting on its own or representing an > organization, that may grant privileges on resources he has authority = upon > - Note: the act of granting privileges may be manual (i.e. through an > interaction) or automatic (i.e. through predefined rules). > > Feedbacks / discussion > > - As some point we suggested "The RO may decide to remove its consent > at any time." Tom provided useful feedback > on > that. Moved to access token where it fits more naturally. > > End-user > > - Definition: physical person that operates with the client software > - Note: that physical person may or may not be the same entity as the > RO > > Access token > > - Definition: digitally signed data that contains specific rights > and/or attributes > - Note 1: the access token can be issued to an end-user (usually > requiring his authentication) and subsequently refreshed. The AS usual= ly > provides a method for the RO to revoke the privileges at any point in = time. > - Note 2: an access token may act as a capability (i.e. bearer token) > or require an additional authentication by binding to a key (i.e. boun= d > token) > > Feedbacks / discussion > > - Would require the subdefinitions right: ability for an end-user to > perform a given operation (or action) on a resource (or object) under = the > control of a RS / attribute: property related to an end-user. > - Note 2 is here in relationship with PR 129 > > > Grant > > - Definition (verb): to permit, as a privilege given to an end-user to > exercise some rights and/or assert attributes during a specific durati= on > - Definition (noun): the act of granting > > Key > > - Definition: public cryptographic binding a request to the holder of > a private key, used by the protocol entities (AS, RS, client instance, > bound token, etc.) to identify themselves. > - Note: a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > Feedbacks / discussion > > - Denis thinks the term "key" is well understood and doesn't need to > be defined. Yet, I tend to believe we'd gain to keep it. First the gen= eric > term "key" may be many things : symmetric/asymmetric, public/private, = etc. > It's also useful to explain its use in the protocol > > Resource > > - Definition: protected API served by a RS and accessed by a client, > if and only if a valid access token is provided > > > > On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault > wrote: > > Hi Yaron, > > > > Yes I highlighted that this was a new term. We can deal with it as a > separate issue indeed. > > > > Best > > Fabien > > > > On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer > wrote: > > Hi Fabien, > > > > Yes, we definitely need to reach closure on terminology, thank you for > driving this discussion! > > > > One process comment: unless I=E2=80=99m missing something, the Interact (= or > Interaction) Server is not mentioned in the current draft. I suggest we d= o > not introduce new functional components or new behaviors as part of the > terminology discussion. Specifically, if the IS is useful, let=E2=80=99s = reach > consensus on that separately. Then we can add it into the Terminology > section. > > > > Thanks, > > Yaron > > > > *From: *TXAuth on behalf of Fabien Imbault < > fabien.imbault@gmail.com> > *Date: *Friday, December 11, 2020 at 14:31 > *To: *Denis > *Cc: *GNAP Mailing List > *Subject: *Re: [GNAP] Terminology proposal > > > > Hi Denis, > > > > Thanks for your detailed feedback. My comments are embedded into your > message. Again those comments are my own, and we'll need to converge to > some consensus beyond what I say here. My main open question is really > about the RO being optional. Could you explain? > > > > Fabien > > > > On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: > > This is a global response to the definitions proposal. > > > TerminologyI propose to adopt the way ISO defines how to write the > definitions.It is a *single sentence* that may be substituted to the > wording being defined in the context of a sentence that uses that > definition. > Since this single sentence can be substituted to the wording, there is no= t > point at the end of that sentence. The sentence does not > have a "a" or "the" in front of it. > > > > [FI] In the first version, I was mostly trying to not get too far away > from the current text. But yes that's a good idea, it gives a more formal > rule, which has been proven to work. > > > > If more information is useful to understand the wording, it is placed in > one or more notes afterwards. > > > > Note: The ISO rules for drafting definitions are in the ISO/IEC > Directives, Part 2 (edition 2018): > > 16.5.6 Definitions > > The definition shall be written in such a form that it can replace the > term in its context. It shall not start with an article (=E2=80=9Cthe=E2= =80=9D, =E2=80=9Ca=E2=80=9D) nor > end with a full stop. > A definition shall not take the form of, or contain, a requirement. > > Only one definition per terminological entry is allowed. If a term is use= d > to define more than one concept, a separate terminological entry shall be > created > for each concept and the domain shall be included in angle brackets befor= e > the definition. > > Circular definitions, which repeat the term being defined, are not allowe= d. > > Comments are inserted between the lines. > > > > Hello everyone, > > > > As an editor : a quick reminder that terminology issues will be discussed > in the coming weeks, and we're expecting your inputs right now (according > to the process previously sent on the mailing list). > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 > > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > > > > The rest of this message is a proposal written in my own name, and doesn'= t > involve discussions with the editors/chairs who might have different > opinions. > Authorization Server (AS) > > Manages the granting of privileges to a third-party client instance. If > the RO consents to at least a part of what is requested, the AS issues an > access token to the client. > > *My questions: * > > *- was else do we issue? (e.g. id claims, payment info, etc.) We could > have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D = is not clear. I > removed that for now.* > > *- there might potentially be several AS, currently we don=E2=80=99t refl= ect that > anywhere. If would leave that as an open item, depending on what we end u= p > doing in the spec* > > I am not in favour of this definition: A RO as defined later: "authorizes > the request to access a protected resource from the RS to the client". > This does not mean in any way that a RO has necessarily a direct > relationship with one or more ASs. [FI] indeed we could remove that > limitation, to have a more general definition > Using the ISO style for definitions, I propose: > > Authorization Server (AS): server that grants rights and/or attributes to > a particular end-user and that provides them to a client in the form of a= n > access token > > Since this definition is using the words "rights" and "attributes", these > two terms need to be defined as well. > > right: ability for an end-user to perform a given operation on an object > under the control of a RS > > attribute: property related to an end-user > > > > [FI] I like your proposal in general. There might be some discussions on > the details. I don't think it makes sense to grant "attributes". > > Some explanations: a "right" is able to support a capability scheme. An > "attribute" is able to support an ACL scheme. > > These two schemes are able to support "discretionary access control" wher= e > the end-user has a "need-to-know". > > However, some attributes are also able to support what was called in the > past "mandatory access control"; for example, > > if the end-user is cleared to "top-secret / marketing strategy". > > > > Interact Server (IS) - this is a new proposed term > > Manages the front-end interaction with the RO, in order to gather its > consent. Depending on the deployment model and the privacy requirements, > the IS may be a component of the AS, or may be distinct and managed by > another party. > > Example : an IS usually involves a web interface accessed by RO through a > web browser. > > Note : an IS is not always required, especially if the access is granted > through automated policies. > > Using the ISO style for definitions, I propose: > > > > Interact*ion* Server (IS) > > component from the AS or server interfacing with an AS that manages the > interactions with a RO, in order to gather its authorizationNote : since > the RO is an optional component, the IS is also an optional component. > > > > [FI] indeed IS is optional. note for myself when looking at RO : why is R= O > optional ? > > Client Requests privileges from the AS, and uses access tokens at the RS. > This specification differentiates between a specific instance (the client > instance, identified by its unique public key) > and the software running the instance (the client software). . For some > kinds of client software, there could be many instances of a single piece > of client software. > The AS determines which policies apply to a given client instance, > including what it can request and on whose behalf. > > Some comments: The above text is stating: "(the client instance, > identified by its unique public key)". > A client instance may use a public key, but that key is not necessarily > unique, in particular when there are multiple ASs. > > [FI] yes, although when possible I would still consider a better practice > to expose a key to a specific AS and not to the entire set of available > ASs. > > Example : a client can be a mobile application or a web application (the > client software) that requires authorizations from the RO to retrieve > content from various protected APIs. The client instance may for instance > refer to a specific version of that client software. > > *See on-going discussion : > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 > (client > instance). * > > Using the ISO style for definitions, I propose: > > Client: application used by an end-user to interact with an AS or a RS > > Note: a client can be a mobile application or a web application [FI] for > me those are just examples, because there could me more (ex IoT device) > > [FI] you remove the entire discussion on client instance / client > software, is that on purpose because you think it's not useful/right, or = is > it because of something else? (maybe add your comment of the related > issue) > > Resource Server (RS) > > Accepts valid access tokens from the client issued by the AS and serves > protected resources on behalf of the RO. There could be multiple RSs > protected by the AS that the client may call. > > Example : a RS is often composed of protected APIs that can be consumed b= y > authorized client software. > > One comment: a RO is not necessarily involved. [FI] a bit hard to > imagine, there's some kind of owner. Could you be more explicit? > Using the ISO style for definitions, I propose: > > Resource Server (RS): server that accepts valid access tokens from client= s > issued by one or more ASs which are used to grant or deny some requested > operations > > Note: a RS is often composed of protected APIs that can be consumed by > clients. > > > > Resource Owner (RO) > > Authorizes the request to access a protected resource from the RS to the > client. The RO may decide to remove its consent at any time. > > Note : the RO may be a physical person or may represent an organization. > > > > Two comments: In order to avoid confusion with the end-user consent, the > word " authorization" is being used instead of "consent". [FI] ok > > It should be said that the RO is an optional component. [FI] why? Using > the ISO style for definitions, I propose: > > Resource Owner (RO): physical person acting on its own or representing an > organization that authorizes to clients operations on protected resources > from a RS > > Note: The RO is an optional component that may interact either with one R= S > or with one or more ASs ,e.g. using an IS. > > End-user =E2=80=93 this was previously Requesting Party RQ > > A physical person that operates and interacts with the client software. > > Note : the end-user may or may not be the same entity as the RO. > > The Note is slightly incorrect. the *physical person* may or may not be > the same entity as the RO. [FI] I didn't understand your comment > Using the ISO style for definitions, I propose: > > End-user : physical person that operates and interacts with the client > software > > Note : that physical person may or may not be the same entity as the RO. > > > > Access Token > > A set of privileges delegated to the client instance for a specific > end-user. An access token is created by the AS, consumed and verified by > the RS, and issued to and carried by the client's end-user on behalf of t= he > RO. The contents and format of the access token are opaque to the client. > > Example : JWT is a commonly used format. > > Note 1 : an access token generally has a limited duration, after which it > may be refreshed at a regular interval. > > Note 2 : an access token may be revoked at any time by the RO. > > Note 3 : an access token may act as a capability or require an additional > authentication by binding to a key > > A fundamental point: the third sentence from the definition states: "The > contents and format of the access token are opaque to the client". > > [FI] I'll check your other thread dedicated to that issue > > See my other email sent today about "RS-Token Introspection or RC-Token > Introspection" where I conclude: > > For end-users caring about their privacy (or for systems willing to > protect the user's privacy), access tokens should not be considered > to be opaque to RCs nor to RSs and ASs should not support Token > Introspection, whether it is RS-Token Introspection or RC-Token > Introspection. > > The example and the other Notes above should be removed. If needed they > should be placed in the main body of the document. > > Using the ISO style for definitions, I propose: > > Access Token : digitally signed data issued by an Authorization Server > (AS) and consumed by a Resource Server (RS) > that contains rights and/or attributes granted > to a particular end-user > > > > Grant > > The process by which the client requests and is given delegated access to > the RS by the AS through the authority of the RO. > > Using the ISO style for definitions, I propose: > > Grant: permission given to end-user to use a subset of his rights and/or > his attributes at a specific time and for a specific duration > > > > Key > > A public cryptographic binding a request to the holder of a private key. > Access tokens and client instances can be associated with specific keys a= t > a point in time. > > Note : a key can be rotated or revoked by its holder. The protocol > supports the update of the key information. > > "key" is a general term that is well understood and that does not need to > be defined. [FI] I really wouldn't bet on that. We can reuse an existing > definition but it is a central piece so we need to be explicit > > The "definitions" section is not intended to explain what can be done wit= h > the term that is being defined. [FI] ok we can work on that > Until the word "key" is qualified using one or more other terms, this > definition should be removed. > > > > Resource > > A protected API served by the RS and accessed by the client if and only i= f > access has been granted. Access to this resource is delegated by the RO a= s > part of the grant process. > > The second sentence of the definition is not in accordance with the ISO > style or definitions and furthermore this second sentence should be remov= ed > since a RO is an optional element. > > > Using the ISO style for definitions, I propose: > > Resource: protected API served by a RS and accessed by a client, if and > only if access is granted by an access token > > Subject Information > > Information about a subject (usually a RO) that is returned directly to > the client from the AS. > > Note : this information needs to be unique. > > > > This definition exhibits several problems: > > (1) The term "subject" is not defined. > > (2) The information that is returned is for an end-user, i.e. not for "(u= sually > a RO)". > > (3) The Note states : "this information needs to be unique". Does it mean > unique for the AS ? globally unique ? > > This definition should be revisited. [FI] I agree (I myself had many > questions here) > > Denis > > > > *My questions : * > > *- probably we=E2=80=99d need to define subject* > > *Subject : > https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject= +Dictionary+Entry > * > > *- might be useful to clarify the relationship to what identity providers > do * > > > > > > 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 > > --00000000000075021f05b65ea3e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I've updated the wiki with the latest remarks (e= xcept from Tom's comment on client, which needs further thought I think= ).=C2=A0

    Thanks
    Fabien=C2=A0

    Le dim. 13 d=C3= =A9c. 2020 =C3=A0 21:41, Yaron Sheffer <yaronf.ietf@gmail.com> a =C3=A9crit=C2=A0:

    Agreed.

    =C2=A0

    From: Fabien Imbault <= fabien.imbault@gmail.com>
    Date: Sunday, December 13, 2020 = at 21:28
    To: Yaron Sheffer <yaronf.ietf@gmail.com>Cc: Denis <denis.ietf@free.fr>, GNAP Mailing List <txaut= h@ietf.org>
    Subject: Re: [GNAP] Terminology proposal

    =C2=A0

    Ok but if we limit to protected resourc= es, we don't have that problem, so typically is not needed.

    =C2=A0

    On Sun, Dec 13, 2020 at 8:26 PM Yaron Sheffer <yaro= nf.ietf@gmail.com> wrote:

    Hi Fabi= en,

    =C2=A0

    =E2=80=9CTypically=E2=80=9D means =E2=80=9Cusually, though = there may be fully public resources where some operations don=E2=80=99t req= uire any authorization, but I don=E2=80=99t want a normative statement in t= he Terminology section=E2=80=A6=E2=80=9D

    =C2=A0

    Thanks,<= /p>

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

    =C2=A0

    <= span style=3D"font-size:12.0pt;color:black">From: Fabien Imbault <fabien.imbault@gmai= l.com>
    Date: Sunday, December 13, 2020 at 21:21
    To: = Yaron Sheffer <yaronf.ietf@gmail.com>
    Cc: Denis = <denis.ietf@free.fr>, GNAP Mailing List <txauth@ietf.org><= br>Subject: Re: [GNAP] Terminology proposal

    =

    =C2=A0

    <= p class=3D"MsoNormal">Hi Yaron,=C2=A0

    =C2=A0

    Stylistic= comments are very important too. And at some point we'll need a review= from native english speakers in=C2=A0the group (I'm sure Justin and Aa= ron will be of great=C2=A0help here).

    =C2=A0

    Ju= st wondering: what do you mean by "typically"? (ideally I'd r= ather have a definition which is not dependent on use case).<= /p>

    =C2=A0

    As soon as we land on something, I'll update the wi= ki.

    =C2=A0=

    Fabien

    =C2=A0

    =C2=A0

    =C2=A0

    On Sun, Dec 13, 2020 at 8:12 P= M Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    It=E2=80=99s purely = stylistic, but I find the definition of RS (=E2=80=9Cserver that denies ope= rations=E2=80=9D) a bit funny. How about:

    =C2=A0

    Resource S= erver (RS)

    • Definition: server that = provides operations on protected resources; such operations typically requi= re that the client provide valid access tokens issued by an AS

    Thanks,

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

    =C2=A0

    From: Fabien Imbault <fabien.imbault@gmail.com>=
    Date: Sunday, December 13, 2020 at 13:20
    To: Yaron She= ffer <yaronf.ietf@gmail.com>
    Cc: Denis <denis.i= etf@free.fr>, GNAP Mailing List <txauth@ietf.org>
    Subje= ct: Re: [GNAP] Terminology proposal

    =

    =C2=A0

    Hello everyone,=C2=A0

    = =C2=A0

    We're at the = end of the 2 week period, and so I integrated the various feedbacks :=C2=A0=

    =C2=A0

    a) from Yaron's feedback, removed ne= w term "IS" and update issue=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to h= andle the proposal here=C2=A0

    b) integrated Tom's feedback regarding the RO (and moved=C2=A0 to= access token)

    c) defini= tions follow an ISO style as suggested by Denis, which we took as a startin= g point (but I made the=C2=A0modifications I felt were necessary)=

    =C2=A0

    I modified the definitions, notes and examples as = a consequence. You'll also find a summary of discussions for each term,= so that we can keep track of them too.

    =C2=A0

    M= y biggest question is : what should we use as our main vocabulary between p= rivilege/rights/attribute? I tried to clarify, please let me know what you = think. The general idea is that we grant privileges that are delivered unde= r the form of access tokens (which contain rights and/or attributes).

    Regarding whether access toke= ns should be opaque or not, I suggest to remove that from the definition an= d handle that in issue=C2=A0https://git= hub.com/ietf-wg-gnap/gnap-core-protocol/issues/145

    =C2=A0

    All has been consolidated on the wiki too=C2=A0https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/wiki/Terminology so that we have a clearer view of where we stan= d.=C2=A0

    =C2=A0

    Please comment further on the li= st if you have comments,=C2=A0I'll update if necessary (and refer to th= e mailing list url in the comment of the wiki update, from now on). Then ed= itors will review the proposal.=C2=A0

    Here is a copy of=C2=A0https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/wiki/Terminology#latest-discussion-update.

    =C2=A0

    Latest discussion update

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

    Author= ization Server (AS)

    • Definition: ser= ver that grants privileges to a particular end-user and that provides them = to a client in the form of an access token
    Feed= backs / discussion / questions :
    • Su= ggested "privilege" definition (that we would probably add as an = additional sub-entry): "A privilege is the right to perform an operati= on (or action) on a Resource." See also=C2=A0other def
    • Note that we don't include claims in the definition= (cf OIDC/SSI integration), but since we talk about a "particular end-= user" it is assumed somehow
    • Den= is suggested we used "rights and attributes" instead of privilege= s. [FI] However i don't think one can really speak about granting attri= butes, except indirectly (ABAC). See access token for more on that, where w= e can be more specific.
    • Do we allow = cases such as distributing the AS on a mobile? (in this case we're at t= he limit of what we call a server)

    Client<= /h2>
    • Definition: application used by an end-user to interact = with an AS or a RS
    • Note: this spec= ification differentiates between a specific instance (the client instance, = identified by its public key) and the software running the instance (the cl= ient software). For some kinds of client software, there could be many inst= ances of a single piece of client software.
    • Example: a client can be a mobile application, a web application, e= tc.

    Feedbacks / discussion :

    • Replaces previously proposed RC, we wouldn't prov= ide a short name.
    • Keep OAuth2 term, = but we clarify it
    • Further discussion= on=C2=A0Client instance

    = R= esource Server (RS)

    • Definition: ser= ver that denies operations on protected resources, unless the client provid= es valid access tokens issued by an AS

    Feedback= s / discussion :

    • Denis suggests to = make explicit that we could have several ASs - "issued by one or more = ASs" (also we'd need a convention on how to denote plural, e.g. AS= s). Not exactly sure right now of the multiple issuance would work, so need= s to be clarified. Also not sure if that's even necessary (do we lack i= n generality if we keep the singular?)

    Resource Owner (RO)

    • Definition: physical person acting on it= s own or representing an organization, that may grant privileges on resourc= es he has authority upon
    • Note: the= act of granting privileges may be manual (i.e. through an interaction) or = automatic (i.e. through predefined rules).
    Feed= backs / discussion

    • As some point we= suggested "The RO may decide to remove its consent at any time."= Tom provided=C2=A0useful f= eedback=C2=A0on that. Moved to access token where it fits more naturall= y.

    End-user

    • Definition: = physical person that operates with the client software=
    • Note: that physical person may or may not be the same en= tity as the RO

    Access token

    • Definition: digitally signed data that contains specific rights and/or = attributes
    • Note 1: the access token = can be issued to an end-user (usually requiring his authentication) and sub= sequently refreshed. The AS usually provides a method for the RO to revoke = the privileges at any point in time.
    • <= span style=3D"font-size:12.0pt;font-family:"Segoe UI",sans-serif"= >Note 2: an access token may act as a capability (i.e. bearer token) or req= uire an additional authentication by binding to a key (i.e. bound token)

    Feedbacks / discussion

    <= ul type=3D"disc">
  • Would require the subdefinitions right: ability for an end-us= er to perform a given operation (or action) on a resource (or object) under= the control of a RS / attribute: property related to an end-user.
  • Note 2 is here in relationship with=C2=A0PR 129
    • Grant=
    • Definition (verb): to permit, as a privilege given = to an end-user to exercise some rights and/or assert attributes during a sp= ecific duration
    • Definition (noun): t= he act of granting

    Key

    • D= efinition: public cryptographic binding a request to the holder of a privat= e key, used by the protocol entities (AS, RS, client instance, bound token,= etc.) to identify themselves.
    • Note:= a key can be rotated or revoked by its holder. The protocol supports the u= pdate of the key information.

    Feedbacks / discu= ssion

    • Denis thinks the term "k= ey" is well understood and doesn't need to be defined. Yet, I tend= to believe we'd gain to keep it. First the generic term "key"= ; may be many things : symmetric/asymmetric, public/private, etc. It's = also useful to explain its use in the protocol

      • Resource

      • Definition: protected API served by a RS an= d accessed by a client, if and only if a valid access token is provided

    =C2=A0=

    On Fri, Dec 11, 2020 at 6:05 PM= Fabien Imbault <fabien.imbault@gmail.com> wrote:=

    Hi Yaron,=C2=A0<= /u>

    =C2=A0

    Yes I highlighted that this was a new term. We can= deal with it as a separate issue indeed.=C2=A0

    =C2=A0

    Best

    Fabien

    =C2=A0

    On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,

    =C2=A0

    Yes, we defin= itely need to reach closure on terminology, thank you for driving this disc= ussion!

    =C2=A0

    One process comment: unless I=E2=80=99m missing somethi= ng, the Interact (or Interaction) Server is not mentioned in the current dr= aft. I suggest we do not introduce new functional components or new behavio= rs as part of the terminology discussion. Specifically, if the IS is useful= , let=E2=80=99s reach consensus on that separately. Then we can add it into= the Terminology section.

    =C2=A0=

    Thanks,

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

    = =C2=A0

    From: TXAuth <txauth-bounces@ietf.org> on behalf o= f Fabien Imbault <fabien.imbault@gmail.com>
    Date: Friday, December 11, 2020 at 14:31
    To: Denis <denis.ietf@free= .fr>
    Cc: GNAP Mailing List <txauth@ietf.org>
    = Subject: Re: [GNAP] Terminology proposal

    =

    =C2=A0

    Hi Denis,=C2=A0

    =C2=A0

    Thanks for your= detailed feedback. My comments are embedded into your message. Again those= comments are my own, and we'll need to converge to some consensus beyo= nd what I say here. My main open question is really about the RO being opti= onal. Could you explain?

    =C2=A0

    Fabien=C2=A0<= /u>

    =C2=A0

    On Fri, Dec 11, 2020 at 12:08 PM Denis <<= a href=3D"mailto:denis.ietf@free.fr" target=3D"_blank" rel=3D"noreferrer">d= enis.ietf@free.fr> wrote:

    This is a global response to the definitions = proposal.

    =C2=A0=

    Terminol= ogy

    I propose to adopt the way ISO defines how to write the d= efinitions.

    It is a single sentence that may be substituted to the wor= ding being defined in the context of a sentence that uses that definition. =
    Since this single sentence can be substituted to the wording, there is = not point at the end of that sentence. The sentence does not
    have a &qu= ot;a" or "the" in front of it.

    =C2=A0

    [FI]=C2=A0In the = first version, I was mostly trying to not get too far away from the current= text.=C2=A0But=C2=A0yes that's a good idea, it gives a more formal rule, which = has been proven to work.=C2=A0

    =

    =C2=A0

    If more information is useful to understand the wording, it = is placed in one or more notes afterwards.

    =C2=A0

    Note: The ISO rules for drafting definitions are in the ISO/IEC Directive= s, Part 2 (edition 2018):

    16.5.6=C2=A0= =C2=A0=C2=A0 Definitions

    The definitio= n shall be written in such a form that it can replace the term in its conte= xt. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca= =E2=80=9D) nor end with a full stop.
    A definition shall not take the fo= rm of, or contain, a requirement.

    Only one definition per terminolog= ical entry is allowed. If a term is used to define more than one concept, a= separate terminological entry shall be created
    for each concept and th= e domain shall be included in angle brackets before the definition.

    = Circular definitions, which repeat the term being defined, are not allowed.=

    Comments are inserted betwee= n the lines.

    =C2= =A0

    Hello everyone,=C2=A0 =

    =C2=A0

    As an editor : a quick reminder that terminology=C2=A0issues= will be discussed in the coming weeks, and we're expecting your inputs= right now (according to the process previously sent on the mailing list).<= u>

    = =C2=A0

    The rest of this = message is a proposal written in my own name, and doesn't involve discu= ssions with the editors/chairs who might have different opinions.=C2=A0 =

    Authorization Server (AS)

    Manages the gra= nting of privileges to a third-party client instance. If the RO consents to= at least a part of what is requested, the AS issues an access token to the= client.

    My questions:

    - was else do we issue? (e.g. id claims, payme= nt info, etc.) We could have more than access tokens, but =E2=80=9Cdirected= information=E2=80=9D is not clear. I removed that for now.

    - there mig= ht potentially be several AS, currently we don=E2=80=99t reflect that anywh= ere. If would leave that as an open item, depending on what we end up doing= in the spec

    I am not in favour of this definition: A RO as defined l= ater: "authorizes the request to access a protected resource from the = RS to the client".
    This does not mean in any way that a RO has nec= essarily a direct relationship with one or more ASs.     [FI] indeed we could re= move that limitation, to have a more general definition

    Using the ISO style = for definitions, I propose:

    Authorizati= on Server (AS): server that grants rights and/or attributes to a particular= end-user and that provides them to a client in the form of an access token=

    Since this definition is= using the words "rights" and "= ;attributes", these two terms need to be defined as well.

    right: ability for an end-user to perform a given operation= on an object under the control of a RS

    attribute: property related to an end-user

    =C2=A0<= /p>

    [FI] I like = your proposal in general. There might be some discussions on the details. I= don't think it makes sense to grant "attributes".=C2=A0=C2= =A0=C2=A0

    Som= e explanations: a "right" is able to support a capability scheme.= An "attribute" is able to support an ACL scheme. <= u>

    These two schemes are able to support "discreti= onary access control" where the end-user has a "need-to-know"= ;.

    However, some attributes are also = able to support what=C2=A0 was called in the past "mandatory access co= ntrol"; for example,

    if the end-= user is cleared to "top-secret / marketing strategy".

    =C2=A0

    =

    Interact Server (IS) - = this is a new proposed term

    Manages the front-end interaction with the RO, in or= der to gather its consent. Depending on the deployment model and the privac= y requirements,
    the IS may be a component of the AS, or may be distinct= and managed by another party.

    Example : an IS usually involves a web interface a= ccessed by RO through a web browser.

    Note : an IS is not always required, especi= ally if the access is granted through automated policies.<= /u>

    Using the IS= O style for definitions, I propose:

    =C2=A0

    Interact<= u>ion Server (IS)

    component from the AS or server interfacing w= ith an AS that manages the interactions with a RO, in order to gather its a= uthorization

    Note : since the RO is an optional component, the IS is also a= n optional component.

    =C2=A0

    [FI] indeed IS is optional. note f= or myself when looking at RO : why is RO optional ?=C2=A0=C2=A0

    Client

    Requests privileges from the AS, and uses access tokens at the RS. Th= is specification differentiates between a specific instance (the client ins= tance, identified by its unique public key)
    and the software running th= e instance (the client software). . For some kinds of client software, ther= e could be many instances of a single piece of client software.
    The AS d= etermines which policies apply to a given client instance, including what i= t can request and on whose behalf.

    Some comments: = The above text is stating: "(the client = instance, identified by its unique public key)".
    A client instance= may use a public key, but that key is not necessarily unique, in particula= r when there are multiple ASs.

    [FI] yes, alth= ough when possible I would still consider a better practice to expose a key= to a specific AS and not to the entire set of available ASs.=C2=A0<= u>

    Example : a client can be a mobile application or a web applicatio= n (the client software) that requires authorizations from the RO to retriev= e content from various protected APIs. The client instance may for instance= refer to a specific version of that client software.<= /p>

    See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protocol/pu= ll/132 (client instance).

    Using the ISO st= yle for definitions, I propose:

    <= span style=3D"font-size:12.0pt;font-family:"Arial",sans-serif;fon= t-weight:normal">Client: application used by an end-user to interact with a= n AS or a RS

    Note: a clien= t can be a mobile application or a web application [FI] for me those are jus= t examples, because there could me more (ex IoT device)

    [FI] you remove the entire discussion on client instance / = client software, is that on purpose because you think it's not useful/r= ight, or is it because of something else? (maybe add your comment of the re= lated issue)=C2=A0 =C2=A0

    Resource Server (RS)

    Accepts valid access tokens from the client issued b= y the AS and serves protected resources on behalf of the RO. There could be= multiple RSs protected by the AS that the client may call.

    Example : a RS is = often composed of protected APIs that can be consumed by authorized client = software.=C2=A0

    One comment: a RO is not necessarily involved. [FI] a bit= hard to imagine, there's some kind of owner. Could you be more explici= t?

    Resource Server (RS): server that accepts valid access tokens fr= om clients issued by one or more ASs which are used to grant or deny some r= equested operations

    = Note= : a RS is often composed of protected APIs that can be consumed by clients.=

    =C2=A0

    Resource Owner (RO)

    Authorizes the= request to access a protected resource from the RS to the client. The RO m= ay decide to remove its consent at any time.

    Note : the RO may be a physical p= erson or may represent an organization.

    =C2=A0

    Two comments: In order to avoid confusion with the end-user co= nsent, the word " authorization" is being used instead of "c= onsent". [FI] ok=C2=A0

    It should be said that the RO is an optional component.=C2=A0[FI] why? Using the ISO style for definitions, = I propose:

    Resource Owner (RO): physical= person acting on its own or representing an organization that authorizes t= o clients operations on protected resources from a RS<= /p>

    Note: The RO is an optional component that ma= y interact either with one RS or with one or more ASs ,e.g. using an IS.

    End-user =E2=80=93 this was previously Requesting Party RQ<= /u>

    A physical person t= hat operates and interacts with the client software. <= /p>

    Note : the end-user may = or may not be the same entity as the RO.

    The Note is slightly incorrect. the physical person may or may not be the same entity as the RO. [FI] I didn't understand your comment

    Using the ISO style= for definitions, I propose:

    End-user :=C2=A0 physical person that operates a= nd interacts with the client software

    Note : that physical person may or may n= ot be the same entity as the RO.

    =C2=A0

    Access Token

    A set of privileges delegated to= the client instance for a specific end-user. An access token is created by= the AS, consumed and verified by the RS, and issued to and carried by the = client's end-user on behalf of the RO. The contents and format of the a= ccess token are opaque to the client.

    Example : JWT is a commonly used format.=

    N= ote 1 : an access token generally has a limited duration, after which it ma= y be refreshed at a regular interval.

    Note 2 : an access token may be revoked = at any time by the RO.

    Note 3 : an access token may act as a capability or require an addit= ional authentication by binding to a key

    A fundamental point: the third sentence from t= he definition states: "The contents and = format of the access token are opaque to the client".=

    [FI] I'll check your other thread dedicated to that issu= e=C2=A0

    See m= y other email sent today about "RS-Token Introspection or RC-Token Int= rospection" where I conclude:

    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 For end-users caring about their privacy (or fo= r systems willing to protect the user's privacy), access tokens should = not be considered
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to be opaque to RCs nor to RSs and= ASs should not support Token Introspection, whether it is RS-Token Introsp= ection or RC-Token Introspection.

    The example and the other Notes = above should be removed. If needed they should be placed in the main body o= f the document.

    Using the IS= O style for definitions, I propose:

    Acc= ess Token := digitally signed data issued by an Authorization Server (AS) and consumed = by a Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 that contains rights= and/or attributes granted to a particular end-user    =

    =C2=A0

    Grant=

    T= he process by which the client requests and is given delegated access to th= e RS by the AS through the authority of the RO.

    Usi= ng the ISO style for definitions, I propose:

    Grant: permission given to end-user to use a subset of his rights and/or = his attributes at a specific time and for a specific duration=

    =C2= =A0

    Key

    A public cryptographic binding a request to the ho= lder of a private key. Access tokens and client instances can be associated= with specific keys at a point in time.

    Note : a key can be rotated or revo= ked by its holder. The protocol supports the update of the key information.=

    "key" is a general term that is well understood and that does = not need to be defined. [FI] I really wouldn't bet on that. We can reuse= an existing definition but it is a central piece so we need to be explicit=

    The "definitions&q= uot; section is not intended to explain what can be done with the term that= is being defined. [FI] ok we can work on that
    Until t= he word "key" is qualified using one or more other terms, this de= finition should be removed.

    =C2=A0

    Resource

    = A pr= otected API served by the RS and accessed by the client if and only if acce= ss has been granted. Access to this resource is delegated by the RO as part= of the grant process.

    The second sentence of the definition is not in acc= ordance with the ISO style or definitions and furthermore this second sente= nce should be removed since a RO is an optional element.

    =C2=A0

    Using the ISO style for definitions, I propose:

    Resource: prot= ected API served by a RS and accessed by a client, if and only if access is= granted by an access token

    Subject Information

    Information about a subject (usually a RO)= that is returned directly to the client from the AS.<= /p>

    Note : this information need= s to be unique.

    =C2=A0

    This definition exhibits several p= roblems:

    (1) The term "subject" is not defi= ned.

    (2) The information that is retu= rned is for an end-user, i.e. not for = "(usually a RO)". =

    (3) The Note states : "this = information needs to be unique". Does it mean unique for the AS ? glob= ally unique ?

    This definition should be revisited. [FI] I agree (I myself had many que= stions here)

    Denis

    =C2=A0

    My questions :

    - probably we=E2=80=99d need to d= efine subject

    Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67= 600697/Subject+Dictionary+Entry

    - might be useful to clarify the relati= onship to what identity providers do=C2=A0

    =C2=A0

    =

    =C2=A0

    Cheers

    Fabien=

    =C2=A0

    =C2=A0

    =C2=A0

    =C2=A0

    = =C2=A0

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

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

    <= /blockquote><= /div> --00000000000075021f05b65ea3e4-- From nobody Sun Dec 13 14:24:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC633A0C54 for ; Sun, 13 Dec 2020 14:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=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 2GvCdfVtzj5t for ; Sun, 13 Dec 2020 14:24:39 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 62A7B3A0B44 for ; Sun, 13 Dec 2020 14:24:39 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id x13so13966794oto.8 for ; Sun, 13 Dec 2020 14:24: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=FGO5BS7OM18vwXYKk0Qo88WZelphjhkLbJmoPK1wl1k=; b=cA/9AyPsK10W9bD9CfnV4euyD/PTZgtToLUosWawo+KxqjgFYYEPPN5PX30j5TnvK9 Ro7IPYcRqkdNwo0WWdohzzWYVGNiFRxp5dPCkChSeOQ083xdUUhXYlen7M6EFyDlFZ3V gf2/op1R35VM6cjtJoAzxFn6RDTEOVT8TUybEVLGA4Y8vHqFG/obxZz2oPoMvzqv6kTf f1oinPFUUpHEsGKpHp6mZCKonZ5b4sSA41jbAputY8NUA3zcQ22Hj+lDDgzXPESC7Pb8 KsBfBc07MqpJQjmx7JaQzranKoZhe8krMOD5inkVc5fTsB4R3ia/itsXWM8cnRfy5X5B vt1Q== 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=FGO5BS7OM18vwXYKk0Qo88WZelphjhkLbJmoPK1wl1k=; b=jo/+5YHyENE/Yzj0TpDBnkK83aSL9egnrvoVN5s5JZftZZugO4nth1nS6truU7OTaP sOTWIQCLuNzRj7u/iO4Hh+cSxCvW7XBa5Anfo+SEijY3o79nlgAIjplHeQBtC+e1CuZl 8f/uaaeRLCnMVSGahJIWt84AnMeJqGoE0tO+ly5Es0QKhO43bjGmfEBF/TJYzwUVrWCy Yi/OVC4vZ3yZMTjKTClRrKX7uLCOLO2LxGUkWugdoUwkfsSqOvSlXHt8m6hyE7JjGtEC KEcAAU045DtYF5yntTM1ORspXG/QUB1GRjm5QHVJc72niOaAOMtO1m0O518Bgb2Xdkto VofA== X-Gm-Message-State: AOAM5329iL5Uc95OFzIidWXNadP3S5qe2rq4sYTHtEOVo4xIcy4CMryb ChNhcU5Lta8eUwq9vmmRpmin2umdfcSTKg49OPE= X-Google-Smtp-Source: ABdhPJxT03jh6t5LzovA6bLoV11hijAmNBuoJms9wXaApB5zMGECoq8uTyf1kkviSabFOldC5i5iuEACl4qS6Hkjn28= X-Received: by 2002:a9d:37c4:: with SMTP id x62mr16692779otb.87.1607898278689; Sun, 13 Dec 2020 14:24:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Sun, 13 Dec 2020 14:24:27 -0800 Message-ID: To: Fabien Imbault Cc: txauth gnap Content-Type: multipart/alternative; boundary="000000000000bc7f0205b65ffd7b" Archived-At: Subject: Re: [GNAP] client definition 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, 13 Dec 2020 22:24:43 -0000 --000000000000bc7f0205b65ffd7b Content-Type: text/plain; charset="UTF-8" It could be the RO or a guardian for the RO so user is the right term. Peace ..tom On Sun, Dec 13, 2020 at 10:42 AM Fabien Imbault wrote: > Hi, > > Thanks for the feedback. Highly use case specific seems a bit of an > overstatement, I would say it is the most common case. But I get your point. > We've tried to be more specific on end-user vs RO. In your proposal I > guess the user you're referring to is the RO. > > I find the suggested definition a bit convoluted, let's think about it a > bit more. > > Cheers > Fabien > > > On Sun, Dec 13, 2020 at 7:04 PM Tom Jones > wrote: > >> This definition is highly use case specific. It leaves out the >> possibility of (eg) a self-issued identifier where the RP displays a >> request to the user on a web page, the user clicks the button and the >> result is that a wallet on the user's device acting as the AS sends an >> access token to the RP (which is typically the client in an OAUTH sense.) >> The underlined part is often incorrect. >> >> Client >> >> - Definition: application *used by an end-user* to interact with an >> AS or a RS >> >> suggestion: Client, an application that desires to get access privileges >> from a user to resources on an RS, possibly by way of an AS. >> >> Peace ..tom >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000bc7f0205b65ffd7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000004c7bee05b66021e6-- From nobody Mon Dec 14 00:01:35 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9863A0A42 for ; Mon, 14 Dec 2020 00:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcNbrAZeA0vr for ; Mon, 14 Dec 2020 00:01:27 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834E73A0A05 for ; Mon, 14 Dec 2020 00:01:27 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id q1so15006196ilt.6 for ; Mon, 14 Dec 2020 00:01:27 -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=fhcHjIu/rkh21/W4ozTXWuQTNH+tTubCCozGePWUgIA=; b=h2B1zPxC/MDLG5SMnKchcRR8HiZVNoFN2zVzWhNk5uJyu8o5q2U3RHCoJfWOxJkXsU T7CFk6H9JSwX+kjOxnoe2O3fnEN6cP4PKsvKcukHuzj2IfRnI6+clcVIoNU2XwylzElN l21LVlPFqb4rui4PF+0pWTKQAJ8G38WtiC1J0zzrsG44g6xmjWeeaM39bWyOKlteFVAp Evv8v88MylhULtYUWYoUJMTK4iDmq8c19RGpzjYotR880H5QDzFqn/Rs4Zojgxl7Z9DE tz6gZBqApYY07NDUh3IGyDpGDCWytkIOenTLdwihY5WS6Wi4HMa4tXaOi49O0pKaKwdI Hhdw== 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=fhcHjIu/rkh21/W4ozTXWuQTNH+tTubCCozGePWUgIA=; b=i6rMcyot3xMqQisCE8oQfKFNccRK1KIu35Jc5eYw3nx9tDIbZuX5szTOg2JCGQs1z1 k+AYH6apS+ewpYDa2N5Jb9JnBKr8VtGW6WgzuEvwrgj4WfD1AFv8HiqUl2G79YyDIohe SmnYgoL89NhcQfYvwqEyGWxaHG1m5/+g+sQACzJktOO1qw3M/Z6rxgk016YtNA8q3n0Y dvSYhLH31O1s1uJOd8bahaun6bD3qMR6+Wfcn94XqDi+ylCFKPgSM97JZ+8OIRI8z+UR eWi8eXHZdTzGg6gxk5Xgi50Qt/1Qjycali73QugZ+b68hvwKZ1v6sq7Gl9wZrXFfDOJR ymgg== X-Gm-Message-State: AOAM532OmgMd7bdZVDEiWhS2RPOz0/+XKJXG9TT/MECrJa+3uu3jajG/ lHREhWj2Tp/pxankzoUkj+amLKbGVQyskcqu4/g= X-Google-Smtp-Source: ABdhPJxobr3Hdbdtb8Wi8M7ulUBVAKJeb7MAUd+D5ONEq/4JxOP9XSEakQLJddzcYzHthfhLGtPhXTTI+mZyuUwI2m4= X-Received: by 2002:a92:aa4c:: with SMTP id j73mr32538920ili.123.1607932886449; Mon, 14 Dec 2020 00:01:26 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> <13422918-A279-45FD-97B7-E02D74534960@gmail.com> In-Reply-To: From: Fabien Imbault Date: Mon, 14 Dec 2020 09:01:15 +0100 Message-ID: To: Tom Jones Cc: Yaron Sheffer , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000008501ce05b6680c00" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 14 Dec 2020 08:01:33 -0000 --0000000000008501ce05b6680c00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Tom. Yes, we now have Yaron's definition, minus the typically. On Sun, Dec 13, 2020 at 11:34 PM Tom Jones wrote: > from the point of view of the GNAP std I would drop typically. If it meet= s > the std then it MUST get an access token. It is the AS that is optional (= at > least i think that is where GNAP is headed.) > Peace ..tom > > > On Sun, Dec 13, 2020 at 11:21 AM Fabien Imbault > wrote: > >> Hi Yaron, >> >> Stylistic comments are very important too. And at some point we'll need = a >> review from native english speakers in the group (I'm sure Justin and Aa= ron >> will be of great help here). >> >> Just wondering: what do you mean by "typically"? (ideally I'd rather hav= e >> a definition which is not dependent on use case). >> >> As soon as we land on something, I'll update the wiki. >> >> Fabien >> >> >> >> On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer >> wrote: >> >>> It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80= =9Cserver that >>> denies operations=E2=80=9D) a bit funny. How about: >>> >>> >>> Resource Server (RS) >>> >>> - Definition: server that provides operations on protected >>> resources; such operations typically require that the client provide= valid >>> access tokens issued by an AS >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> *From: *Fabien Imbault >>> *Date: *Sunday, December 13, 2020 at 13:20 >>> *To: *Yaron Sheffer >>> *Cc: *Denis , GNAP Mailing List >>> *Subject: *Re: [GNAP] Terminology proposal >>> >>> >>> >>> Hello everyone, >>> >>> >>> >>> We're at the end of the 2 week period, and so I integrated the various >>> feedbacks : >>> >>> >>> >>> a) from Yaron's feedback, removed new term "IS" and update issue >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle >>> the proposal here >>> >>> b) integrated Tom's feedback regarding the RO (and moved to access >>> token) >>> >>> c) definitions follow an ISO style as suggested by Denis, which we took >>> as a starting point (but I made the modifications I felt were necessary= ) >>> >>> >>> >>> I modified the definitions, notes and examples as a consequence. You'll >>> also find a summary of discussions for each term, so that we can keep t= rack >>> of them too. >>> >>> >>> >>> My biggest question is : what should we use as our main vocabulary >>> between privilege/rights/attribute? I tried to clarify, please let me k= now >>> what you think. The general idea is that we grant privileges that are >>> delivered under the form of access tokens (which contain rights and/or >>> attributes). >>> >>> Regarding whether access tokens should be opaque or not, I suggest to >>> remove that from the definition and handle that in issue >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 >>> >>> >>> >>> All has been consolidated on the wiki too >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so >>> that we have a clearer view of where we stand. >>> >>> >>> >>> Please comment further on the list if you have comments, I'll update if >>> necessary (and refer to the mailing list url in the comment of the wiki >>> update, from now on). Then editors will review the proposal. >>> >>> Here is a copy of >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology#lat= est-discussion-update >>> . >>> >>> >>> Latest discussion update >>> >>> Here we consolidate the latest proposal(s) from the group. We also >>> include the discussion items (individual feedbacks). >>> Authorization Server (AS) >>> >>> - Definition: server that grants privileges to a particular end-user >>> and that provides them to a client in the form of an access token >>> >>> Feedbacks / discussion / questions : >>> >>> - Suggested "privilege" definition (that we would probably add as an >>> additional sub-entry): "A privilege is the right to perform an opera= tion >>> (or action) on a Resource." See also other def >>> >>> - Note that we don't include claims in the definition (cf OIDC/SSI >>> integration), but since we talk about a "particular end-user" it is = assumed >>> somehow >>> - Denis suggested we used "rights and attributes" instead of >>> privileges. [FI] However i don't think one can really speak about gr= anting >>> attributes, except indirectly (ABAC). See access token for more on t= hat, >>> where we can be more specific. >>> - Do we allow cases such as distributing the AS on a mobile? (in >>> this case we're at the limit of what we call a server) >>> >>> Client >>> >>> - Definition: application used by an end-user to interact with an AS >>> or a RS >>> - Note: this specification differentiates between a specific >>> instance (the client instance, identified by its public key) and the >>> software running the instance (the client software). For some kinds = of >>> client software, there could be many instances of a single piece of = client >>> software. >>> - Example: a client can be a mobile application, a web application, >>> etc. >>> >>> Feedbacks / discussion : >>> >>> - Replaces previously proposed RC, we wouldn't provide a short name. >>> - Keep OAuth2 term, but we clarify it >>> - Further discussion on Client instance >>> >>> >>> Resource Server (RS) >>> >>> - Definition: server that denies operations on protected resources, >>> unless the client provides valid access tokens issued by an AS >>> >>> Feedbacks / discussion : >>> >>> - Denis suggests to make explicit that we could have several ASs - >>> "issued by one or more ASs" (also we'd need a convention on how to d= enote >>> plural, e.g. ASs). Not exactly sure right now of the multiple issuan= ce >>> would work, so needs to be clarified. Also not sure if that's even >>> necessary (do we lack in generality if we keep the singular?) >>> >>> Resource Owner (RO) >>> >>> - Definition: physical person acting on its own or representing an >>> organization, that may grant privileges on resources he has authorit= y upon >>> - Note: the act of granting privileges may be manual (i.e. through >>> an interaction) or automatic (i.e. through predefined rules). >>> >>> Feedbacks / discussion >>> >>> - As some point we suggested "The RO may decide to remove its >>> consent at any time." Tom provided useful feedback >>> on >>> that. Moved to access token where it fits more naturally. >>> >>> End-user >>> >>> - Definition: physical person that operates with the client software >>> - Note: that physical person may or may not be the same entity as >>> the RO >>> >>> Access token >>> >>> - Definition: digitally signed data that contains specific rights >>> and/or attributes >>> - Note 1: the access token can be issued to an end-user (usually >>> requiring his authentication) and subsequently refreshed. The AS usu= ally >>> provides a method for the RO to revoke the privileges at any point i= n time. >>> - Note 2: an access token may act as a capability (i.e. bearer >>> token) or require an additional authentication by binding to a key (= i.e. >>> bound token) >>> >>> Feedbacks / discussion >>> >>> - Would require the subdefinitions right: ability for an end-user to >>> perform a given operation (or action) on a resource (or object) unde= r the >>> control of a RS / attribute: property related to an end-user. >>> - Note 2 is here in relationship with PR 129 >>> >>> >>> Grant >>> >>> - Definition (verb): to permit, as a privilege given to an end-user >>> to exercise some rights and/or assert attributes during a specific d= uration >>> - Definition (noun): the act of granting >>> >>> Key >>> >>> - Definition: public cryptographic binding a request to the holder >>> of a private key, used by the protocol entities (AS, RS, client inst= ance, >>> bound token, etc.) to identify themselves. >>> - Note: a key can be rotated or revoked by its holder. The protocol >>> supports the update of the key information. >>> >>> Feedbacks / discussion >>> >>> - Denis thinks the term "key" is well understood and doesn't need to >>> be defined. Yet, I tend to believe we'd gain to keep it. First the g= eneric >>> term "key" may be many things : symmetric/asymmetric, public/private= , etc. >>> It's also useful to explain its use in the protocol >>> >>> Resource >>> >>> - Definition: protected API served by a RS and accessed by a client, >>> if and only if a valid access token is provided >>> >>> >>> >>> On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault >>> wrote: >>> >>> Hi Yaron, >>> >>> >>> >>> Yes I highlighted that this was a new term. We can deal with it as a >>> separate issue indeed. >>> >>> >>> >>> Best >>> >>> Fabien >>> >>> >>> >>> On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer >>> wrote: >>> >>> Hi Fabien, >>> >>> >>> >>> Yes, we definitely need to reach closure on terminology, thank you for >>> driving this discussion! >>> >>> >>> >>> One process comment: unless I=E2=80=99m missing something, the Interact= (or >>> Interaction) Server is not mentioned in the current draft. I suggest we= do >>> not introduce new functional components or new behaviors as part of the >>> terminology discussion. Specifically, if the IS is useful, let=E2=80=99= s reach >>> consensus on that separately. Then we can add it into the Terminology >>> section. >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> *From: *TXAuth on behalf of Fabien Imbault < >>> fabien.imbault@gmail.com> >>> *Date: *Friday, December 11, 2020 at 14:31 >>> *To: *Denis >>> *Cc: *GNAP Mailing List >>> *Subject: *Re: [GNAP] Terminology proposal >>> >>> >>> >>> Hi Denis, >>> >>> >>> >>> Thanks for your detailed feedback. My comments are embedded into your >>> message. Again those comments are my own, and we'll need to converge to >>> some consensus beyond what I say here. My main open question is really >>> about the RO being optional. Could you explain? >>> >>> >>> >>> Fabien >>> >>> >>> >>> On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: >>> >>> This is a global response to the definitions proposal. >>> >>> >>> TerminologyI propose to adopt the way ISO defines how to write the >>> definitions.It is a *single sentence* that may be substituted to the >>> wording being defined in the context of a sentence that uses that >>> definition. >>> Since this single sentence can be substituted to the wording, there is >>> not point at the end of that sentence. The sentence does not >>> have a "a" or "the" in front of it. >>> >>> >>> >>> [FI] In the first version, I was mostly trying to not get too far away >>> from the current text. But yes that's a good idea, it gives a more >>> formal rule, which has been proven to work. >>> >>> >>> >>> If more information is useful to understand the wording, it is placed i= n >>> one or more notes afterwards. >>> >>> >>> >>> Note: The ISO rules for drafting definitions are in the ISO/IEC >>> Directives, Part 2 (edition 2018): >>> >>> 16.5.6 Definitions >>> >>> The definition shall be written in such a form that it can replace the >>> term in its context. It shall not start with an article (=E2=80=9Cthe= =E2=80=9D, =E2=80=9Ca=E2=80=9D) nor >>> end with a full stop. >>> A definition shall not take the form of, or contain, a requirement. >>> >>> Only one definition per terminological entry is allowed. If a term is >>> used to define more than one concept, a separate terminological entry s= hall >>> be created >>> for each concept and the domain shall be included in angle brackets >>> before the definition. >>> >>> Circular definitions, which repeat the term being defined, are not >>> allowed. >>> >>> Comments are inserted between the lines. >>> >>> >>> >>> Hello everyone, >>> >>> >>> >>> As an editor : a quick reminder that terminology issues will be >>> discussed in the coming weeks, and we're expecting your inputs right no= w >>> (according to the process previously sent on the mailing list). >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >>> >>> >>> >>> The rest of this message is a proposal written in my own name, and >>> doesn't involve discussions with the editors/chairs who might have >>> different opinions. >>> Authorization Server (AS) >>> >>> Manages the granting of privileges to a third-party client instance. If >>> the RO consents to at least a part of what is requested, the AS issues = an >>> access token to the client. >>> >>> *My questions: * >>> >>> *- was else do we issue? (e.g. id claims, payment info, etc.) We could >>> have more than access tokens, but =E2=80=9Cdirected information=E2=80= =9D is not clear. I >>> removed that for now.* >>> >>> *- there might potentially be several AS, currently we don=E2=80=99t re= flect >>> that anywhere. If would leave that as an open item, depending on what w= e >>> end up doing in the spec* >>> >>> I am not in favour of this definition: A RO as defined later: >>> "authorizes the request to access a protected resource from the RS to t= he >>> client". >>> This does not mean in any way that a RO has necessarily a direct >>> relationship with one or more ASs. [FI] indeed we could remove that >>> limitation, to have a more general definition >>> Using the ISO style for definitions, I propose: >>> >>> Authorization Server (AS): server that grants rights and/or attributes >>> to a particular end-user and that provides them to a client in the form= of >>> an access token >>> >>> Since this definition is using the words "rights" and "attributes", >>> these two terms need to be defined as well. >>> >>> right: ability for an end-user to perform a given operation on an objec= t >>> under the control of a RS >>> >>> attribute: property related to an end-user >>> >>> >>> >>> [FI] I like your proposal in general. There might be some discussions o= n >>> the details. I don't think it makes sense to grant "attributes". >>> >>> Some explanations: a "right" is able to support a capability scheme. An >>> "attribute" is able to support an ACL scheme. >>> >>> These two schemes are able to support "discretionary access control" >>> where the end-user has a "need-to-know". >>> >>> However, some attributes are also able to support what was called in >>> the past "mandatory access control"; for example, >>> >>> if the end-user is cleared to "top-secret / marketing strategy". >>> >>> >>> >>> Interact Server (IS) - this is a new proposed term >>> >>> Manages the front-end interaction with the RO, in order to gather its >>> consent. Depending on the deployment model and the privacy requirements= , >>> the IS may be a component of the AS, or may be distinct and managed by >>> another party. >>> >>> Example : an IS usually involves a web interface accessed by RO through >>> a web browser. >>> >>> Note : an IS is not always required, especially if the access is grante= d >>> through automated policies. >>> >>> Using the ISO style for definitions, I propose: >>> >>> >>> >>> Interact*ion* Server (IS) >>> >>> component from the AS or server interfacing with an AS that manages the >>> interactions with a RO, in order to gather its authorizationNote : >>> since the RO is an optional component, the IS is also an optional compo= nent. >>> >>> >>> >>> [FI] indeed IS is optional. note for myself when looking at RO : why is >>> RO optional ? >>> >>> Client Requests privileges from the AS, and uses access tokens at the >>> RS. This specification differentiates between a specific instance (the >>> client instance, identified by its unique public key) >>> and the software running the instance (the client software). . For some >>> kinds of client software, there could be many instances of a single pie= ce >>> of client software. >>> The AS determines which policies apply to a given client instance, >>> including what it can request and on whose behalf. >>> >>> Some comments: The above text is stating: "(the client instance, >>> identified by its unique public key)". >>> A client instance may use a public key, but that key is not necessarily >>> unique, in particular when there are multiple ASs. >>> >>> [FI] yes, although when possible I would still consider a better >>> practice to expose a key to a specific AS and not to the entire set of >>> available ASs. >>> >>> Example : a client can be a mobile application or a web application (th= e >>> client software) that requires authorizations from the RO to retrieve >>> content from various protected APIs. The client instance may for instan= ce >>> refer to a specific version of that client software. >>> >>> *See on-going discussion : >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 >>> (client >>> instance). * >>> >>> Using the ISO style for definitions, I propose: >>> >>> Client: application used by an end-user to interact with an AS or a RS >>> >>> Note: a client can be a mobile application or a web application [FI] >>> for me those are just examples, because there could me more (ex IoT dev= ice) >>> >>> [FI] you remove the entire discussion on client instance / client >>> software, is that on purpose because you think it's not useful/right, o= r is >>> it because of something else? (maybe add your comment of the related >>> issue) >>> >>> Resource Server (RS) >>> >>> Accepts valid access tokens from the client issued by the AS and serves >>> protected resources on behalf of the RO. There could be multiple RSs >>> protected by the AS that the client may call. >>> >>> Example : a RS is often composed of protected APIs that can be consumed >>> by authorized client software. >>> >>> One comment: a RO is not necessarily involved. [FI] a bit hard to >>> imagine, there's some kind of owner. Could you be more explicit? >>> Using the ISO style for definitions, I propose: >>> >>> Resource Server (RS): server that accepts valid access tokens from >>> clients issued by one or more ASs which are used to grant or deny some >>> requested operations >>> >>> Note: a RS is often composed of protected APIs that can be consumed by >>> clients. >>> >>> >>> >>> Resource Owner (RO) >>> >>> Authorizes the request to access a protected resource from the RS to th= e >>> client. The RO may decide to remove its consent at any time. >>> >>> Note : the RO may be a physical person or may represent an organization= . >>> >>> >>> >>> Two comments: In order to avoid confusion with the end-user consent, th= e >>> word " authorization" is being used instead of "consent". [FI] ok >>> >>> It should be said that the RO is an optional component. [FI] why? Using >>> the ISO style for definitions, I propose: >>> >>> Resource Owner (RO): physical person acting on its own or representing >>> an organization that authorizes to clients operations on protected >>> resources from a RS >>> >>> Note: The RO is an optional component that may interact either with one >>> RS or with one or more ASs ,e.g. using an IS. >>> >>> End-user =E2=80=93 this was previously Requesting Party RQ >>> >>> A physical person that operates and interacts with the client software. >>> >>> Note : the end-user may or may not be the same entity as the RO. >>> >>> The Note is slightly incorrect. the *physical person* may or may not be >>> the same entity as the RO. [FI] I didn't understand your comment >>> Using the ISO style for definitions, I propose: >>> >>> End-user : physical person that operates and interacts with the client >>> software >>> >>> Note : that physical person may or may not be the same entity as the >>> RO. >>> >>> >>> >>> Access Token >>> >>> A set of privileges delegated to the client instance for a specific >>> end-user. An access token is created by the AS, consumed and verified b= y >>> the RS, and issued to and carried by the client's end-user on behalf of= the >>> RO. The contents and format of the access token are opaque to the clien= t. >>> >>> Example : JWT is a commonly used format. >>> >>> Note 1 : an access token generally has a limited duration, after which >>> it may be refreshed at a regular interval. >>> >>> Note 2 : an access token may be revoked at any time by the RO. >>> >>> Note 3 : an access token may act as a capability or require an >>> additional authentication by binding to a key >>> >>> A fundamental point: the third sentence from the definition states: "Th= e >>> contents and format of the access token are opaque to the client". >>> >>> [FI] I'll check your other thread dedicated to that issue >>> >>> See my other email sent today about "RS-Token Introspection or RC-Token >>> Introspection" where I conclude: >>> >>> For end-users caring about their privacy (or for systems willing >>> to protect the user's privacy), access tokens should not be considered >>> to be opaque to RCs nor to RSs and ASs should not support Token >>> Introspection, whether it is RS-Token Introspection or RC-Token >>> Introspection. >>> >>> The example and the other Notes above should be removed. If needed they >>> should be placed in the main body of the document. >>> >>> Using the ISO style for definitions, I propose: >>> >>> Access Token : digitally signed data issued by an Authorization Server >>> (AS) and consumed by a Resource Server (RS) >>> that contains rights and/or attributes granted >>> to a particular end-user >>> >>> >>> >>> Grant >>> >>> The process by which the client requests and is given delegated access >>> to the RS by the AS through the authority of the RO. >>> >>> Using the ISO style for definitions, I propose: >>> >>> Grant: permission given to end-user to use a subset of his rights and/o= r >>> his attributes at a specific time and for a specific duration >>> >>> >>> >>> Key >>> >>> A public cryptographic binding a request to the holder of a private key= . >>> Access tokens and client instances can be associated with specific keys= at >>> a point in time. >>> >>> Note : a key can be rotated or revoked by its holder. The protocol >>> supports the update of the key information. >>> >>> "key" is a general term that is well understood and that does not need >>> to be defined. [FI] I really wouldn't bet on that. We can reuse an >>> existing definition but it is a central piece so we need to be explicit >>> >>> The "definitions" section is not intended to explain what can be done >>> with the term that is being defined. [FI] ok we can work on that >>> Until the word "key" is qualified using one or more other terms, this >>> definition should be removed. >>> >>> >>> >>> Resource >>> >>> A protected API served by the RS and accessed by the client if and only >>> if access has been granted. Access to this resource is delegated by the= RO >>> as part of the grant process. >>> >>> The second sentence of the definition is not in accordance with the ISO >>> style or definitions and furthermore this second sentence should be rem= oved >>> since a RO is an optional element. >>> >>> >>> Using the ISO style for definitions, I propose: >>> >>> Resource: protected API served by a RS and accessed by a client, if and >>> only if access is granted by an access token >>> >>> Subject Information >>> >>> Information about a subject (usually a RO) that is returned directly to >>> the client from the AS. >>> >>> Note : this information needs to be unique. >>> >>> >>> >>> This definition exhibits several problems: >>> >>> (1) The term "subject" is not defined. >>> >>> (2) The information that is returned is for an end-user, i.e. not for "= (usually >>> a RO)". >>> >>> (3) The Note states : "this information needs to be unique". Does it >>> mean unique for the AS ? globally unique ? >>> >>> This definition should be revisited. [FI] I agree (I myself had many >>> questions here) >>> >>> Denis >>> >>> >>> >>> *My questions : * >>> >>> *- probably we=E2=80=99d need to define subject* >>> >>> *Subject : >>> https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subje= ct+Dictionary+Entry >>> * >>> >>> *- might be useful to clarify the relationship to what identity >>> providers do * >>> >>> >>> >>> >>> >>> 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 >> > --0000000000008501ce05b6680c00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks Tom. Yes, we now have Yaron's definition, minus= the typically.

    On Sun, Dec 13, 2020 at 11:34 PM Tom Jones <thomasclinganjones@gmail.com> wr= ote:
    from the point of view of the GNAP std I would drop typically. If it = meets the std then it MUST get an access token. It is the AS that is option= al (at least i think that is where GNAP is headed.)
    <= div dir=3D"ltr">
    Peace ..tom

    On Sun, Dec 13, 2020 at 11:21 AM Fabien Imbault <fabien.imbault@gmail.com> w= rote:
    Hi Yaron,=C2=A0

    Stylistic comm= ents are very important too. And at some point we'll need a review from= native english speakers in=C2=A0the group (I'm sure Justin and Aaron w= ill be of great=C2=A0help here).

    Just wondering: w= hat do you mean by "typically"? (ideally I'd rather have a de= finition which is not dependent on use case).

    As s= oon as we land on something, I'll update the wiki.

    =
    Fabien



    On Sun, Dec 13, 2020 at 8:12= PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    = It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9Cse= rver that denies operations=E2=80=9D) a bit funny. How about:=

    =C2=A0

    Resource Server (RS)<= span style=3D"font-family:"Segoe UI",sans-serif;color:rgb(36,41,4= 6)">

    • Definition: server that pr= ovides operations on protected resources; such operations typically require= that the client provide valid access tokens issued by an AS<= /span>

    Thanks,

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

    <= u>=C2=A0

    =

    From: = Fabien Imbault <fabien.imbault@= gmail.com>
    Date: Sunday, December 13, 2020 at 13:20
    = To: Yaron Sheffer <yaronf.ietf@gmail.com>
    Cc: Denis <denis.ietf@free.fr>= , GNAP Mailing List <txauth@ietf.org>
    Subject: Re: [GNAP] Terminology proposa= l

    =C2=A0

    Hello everyone,=C2=A0<= /u>

    =C2=A0

    We're at the end of the 2 week period, and so I integ= rated the various feedbacks :=C2=A0

    =C2=A0

    a) fr= om Yaron's feedback, removed new term "IS" and update issue= =C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/133 to handle the proposal here=C2=A0

    b) integrated Tom's feedback regarding the RO (= and moved=C2=A0 to access token)

    c) definitions follow an ISO style as suggested by Denis, which we= took as a starting point (but I made the=C2=A0modifications I felt were ne= cessary)

    =C2=A0

    I modified the definitions, note= s and examples as a consequence. You'll also find a summary of discussi= ons for each term, so that we can keep track of them too.

    =

    =C2=A0

    My biggest question is : what should we use as our main vo= cabulary between privilege/rights/attribute? I tried to clarify, please let= me know what you think. The general idea is that we grant privileges that = are delivered under the form of access tokens (which contain rights and/or = attributes).

    Regarding w= hether access tokens should be opaque or not, I suggest to remove that from= the definition and handle that in issue=C2=A0https://gith= ub.com/ietf-wg-gnap/gnap-core-protocol/issues/145

    =C2=A0

    All has been consolidated on the wiki too=C2=A0https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Termino= logy so that we have a clearer view of where we stand.=C2=A0<= /u>

    =C2=A0

    Please comment further on the list if you have comm= ents,=C2=A0I'll update if necessary (and refer to the mailing list url = in the comment of the wiki update, from now on). Then editors will review t= he proposal.=C2=A0

    =C2= =A0

    Latest discussion update<= u>

    Here we consolidate the l= atest proposal(s) from the group. We also include the discussion items (ind= ividual feedbacks).

    Authorization= Server (AS)

    • Definition: server= that grants privileges to a particular end-user and that provides them to = a client in the form of an access token

    Feedbacks / discussion / questions :<= /u>

    • Suggested "privilege" definitio= n (that we would probably add as an additional sub-entry): "A privileg= e is the right to perform an operation (or action) on a Resource." See= also=C2=A0other def=
    • Note that we don't include claim= s in the definition (cf OIDC/SSI integration), but since we talk about a &q= uot;particular end-user" it is assumed somehow
    • Denis suggested we used "rights and attributes"= instead of privileges. [FI] However i don't think one can really speak= about granting attributes, except indirectly (ABAC). See access token for = more on that, where we can be more specific.
    • Do we allow cases such as distributing the AS on a mobile? (in t= his case we're at the limit of what we call a server)

    Client

    • Definition: application used by an end-user to interact with an AS o= r a RS
    • Note: this specification di= fferentiates between a specific instance (the client instance, identified b= y its public key) and the software running the instance (the client softwar= e). For some kinds of client software, there could be many instances of a s= ingle piece of client software.
    • Ex= ample: a client can be a mobile application, a web application, etc.=

    Feedbacks / discus= sion :

    • Replaces previously prop= osed RC, we wouldn't provide a short name.
      • Keep OAuth2 term, but we clarify it<= li class=3D"MsoNormal" style=3D"color:rgb(36,41,46);margin-top:3pt;box-sizi= ng:border-box">Further discussion on=C2=A0Client instance

    Resource Server (RS)

    Feedbacks / discussion :

    Resource Owner (RO)
    • Definition: physical person acting on its own or repr= esenting an organization, that may grant privileges on resources he has aut= hority upon
    • Note: the act of grant= ing privileges may be manual (i.e. through an interaction) or automatic (i.= e. through predefined rules).

    Feedbacks / discussion

    End-user<= u>

    • Definition: physical person that opera= tes with the client software
    • Note:= that physical person may or may not be the same entity as the RO=

    Access token
    • Definition: digitally signed data that contains specif= ic rights and/or attributes
    • Note 1= : the access token can be issued to an end-user (usually requiring his auth= entication) and subsequently refreshed. The AS usually provides a method fo= r the RO to revoke the privileges at any point in time.
    • Note 2: an access token may act as a capability (i.e.= bearer token) or require an additional authentication by binding to a key = (i.e. bound token)

    Feedbacks / discussion

      =
    • Would require the subdefinitions right: ability for an end-user to perform= a given operation (or action) on a resource (or object) under the control = of a RS / attribute: property related to an end-user.<= /li>
    • Note 2 is here in relationship with=C2=A0PR 129

    Grant=

    • Definition (verb): to permit, as a privi= lege given to an end-user to exercise some rights and/or assert attributes = during a specific duration
    • Definit= ion (noun): the act of granting

    = Key

    • Definition: public cry= ptographic binding a request to the holder of a private key, used by the pr= otocol entities (AS, RS, client instance, bound token, etc.) to identify th= emselves.
    • Note: a key can be rotat= ed or revoked by its holder. The protocol supports the update of the key in= formation.

    F= eedbacks / discussion

    • Denis th= inks the term "key" is well understood and doesn't need to be= defined. Yet, I tend to believe we'd gain to keep it. First the generi= c term "key" may be many things : symmetric/asymmetric, public/pr= ivate, etc. It's also useful to explain its use in the protocol<= u>

    Resource

    =
    • Definition: protected API served by a RS and accessed by= a client, if and only if a valid access token is provided

    =C2=A0

    On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbau= lt <fabien= .imbault@gmail.com> wrote:

    Hi Yaron,=C2=A0

    =C2=A0

    Yes I highlighted that this was a new term. We can deal with it as a sep= arate issue indeed.=C2=A0

    =C2=A0

    Best<= /u>

    Fabien

    =C2=A0

    On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrot= e:

    Hi Fabien,

    =C2=A0<= /u>

    Yes, we definitely need to reach closure on t= erminology, thank you for driving this discussion!

    =C2=A0

    One process = comment: unless I=E2=80=99m missing something, the Interact (or Interaction= ) Server is not mentioned in the current draft. I suggest we do not introdu= ce new functional components or new behaviors as part of the terminology di= scussion. Specifically, if the IS is useful, let=E2=80=99s reach consensus = on that separately. Then we can add it into the Terminology section.=

    =C2=A0

    Thanks,

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

    =C2=A0

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbau= lt <fabien= .imbault@gmail.com>
    Date: Friday, December 11, 2020 at 14:= 31
    To: Denis <denis.ietf@free.fr>
    Cc: GNAP Mailing List <txauth@ietf.org>Subject: Re: [GNAP] Terminology proposal

    =C2=A0

    Hi Denis,=C2=A0

    =C2=A0

    Thanks for = your detailed feedback. My comments are embedded into your message. Again t= hose comments are my own, and we'll need to converge to some consensus = beyond what I say here. My main open question is really about the RO being = optional. Could you explain?

    =C2=A0

    Fabien=C2=A0=

    =C2=A0

    On Fri, Dec 11, 2020 at 12:08 PM Denis &= lt;denis.ietf@free.= fr> wrote:

    This is a global response to the definitions proposal. <= u>

    =C2=A0

    <= div>

    Terminology

    I propose to ado= pt the way ISO defines how to write the definitions.

    It is a <= i>single sentence that may be subst= ituted to the wording being defined in the context of a sentence that uses = that definition.
    Since this single sentence can be substituted to the w= ording, there is not point at the end of that sentence. The sentence does n= ot
    have a "a" or "the" in front of it.

    =C2=A0=

    = [FI]=C2=A0In the first version, I was mostly trying to not get too far away= from the current text.=C2=A0But=C2= =A0yes that's a good idea, it gives a more fo= rmal rule, which has been proven to work.=C2=A0

    =C2=A0<= /u>

    If more information is useful to understand = the wording, it is placed in one or more notes afterwards.

    =C2=A0

    Note: The ISO rules for drafting definitions are in the I= SO/IEC Directives, Part 2 (edition 2018):

    16= .5.6=C2=A0=C2=A0=C2=A0 Definitions

    The def= inition shall be written in such a form that it can replace the term in its= context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80= =9Ca=E2=80=9D) nor end with a full stop.
    A definition shall not take th= e form of, or contain, a requirement.

    Only one definition per termin= ological entry is allowed. If a term is used to define more than one concep= t, a separate terminological entry shall be created
    for each concept an= d the domain shall be included in angle brackets before the definition.
    =
    Circular definitions, which repeat the term being defined, are not allo= wed.

    Comments are inserted between the li= nes.

    =C2=A0

    Hello everyone,=C2=A0

    =C2=A0

    As an editor : a quick reminder that terminology=C2=A0issues will be disc= ussed in the coming weeks, and we're expecting your inputs right now (a= ccording to the process previously sent on the mailing list).=

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

    The rest of this message is a proposal written in my own name, and doe= sn't involve discussions with the editors/chairs who might have differe= nt opinions.=C2=A0

    Authorization Server (AS)

    Manages t= he granting of privileges to a third-party client instance. If the RO conse= nts to at least a part of what is requested, the AS issues an access token = to the client.

    My questions:

    - was else do we issue? (e.g. id claims, payment inf= o, etc.) We could have more than access tokens, but =E2=80=9Cdirected infor= mation=E2=80=9D is not clear. I removed that for now.<= /u>

    - there might potenti= ally be several AS, currently we don=E2=80=99t reflect that anywhere. If wo= uld leave that as an open item, depending on what we end up doing in the sp= ec

    I am not in favour of this definition: A RO as defined later: "autho= rizes the request to access a protected resource from the RS to the client&= quot;.
    This does not mean in any way that a RO has necessarily a direct= relationship with one or more ASs.     [FI] indeed we could remove that limitation, to have= a more general definition

    Using the ISO style for definitions, I propose:

    Authorization Server (AS): server that grants rights and/or at= tributes to a particular end-user and that provides them to a client in the= form of an access token

    Since this d= efinition is using the words "righ= ts" and "attributes", these two terms need to be defined as = well.

    right: ability for an end-user to perform a given operati= on on an object under the control of a RS

    attribu= te: property related to an end-user

    =C2=A0

    =

    [FI] I like your prop= osal in general. There might be some discussions on the details. I don'= t think it makes sense to grant "attributes".=C2=A0=C2=A0= =C2=A0

    Some explanations: a "= ;right" is able to support a capability scheme. An "attribute&quo= t; is able to support an ACL scheme.

    These two sc= hemes are able to support "discretionary access control" where th= e end-user has a "need-to-know".

    Howeve= r, some attributes are also able to support what=C2=A0 was called in the pa= st "mandatory access control"; for example, =

    if the end-user is cleared to "top-secret / marketing strategy&qu= ot;.

    =C2=A0

    Interact Server (IS) - this is a new propose= d term

    Man= ages the front-end interaction with the RO, in order to gather its consent.= Depending on the deployment model and the privacy requirements,
    the IS= may be a component of the AS, or may be distinct and managed by another pa= rty.

    Exampl= e : an IS usually involves a web interface accessed by RO through a web bro= wser.

    Note= : an IS is not always required, especially if the access is granted throug= h automated policies.

    Using the ISO style for definitions, I propose:

    =C2=A0

    I= nteraction Server (IS)

    component from the AS or server inter= facing with an AS that manages the interactions with a RO, in order to gath= er its authorization

    Note : since the RO is an optional component, the IS is also an opti= onal component.

    =C2=A0

    [FI] indeed IS is optional. note for mys= elf when looking at RO : why is RO optional ?=C2=A0=C2=A0<= /u>

    <= span style=3D"font-size:10pt;line-height:125%;font-family:Arial,sans-serif;= color:rgb(36,41,46)">Client=

    Requests privileges from the = AS, and uses access tokens at the RS. This specification differentiates bet= ween a specific instance (the client instance, identified by its unique pub= lic key)
    and the software running the instance (the client software). .= For some kinds of client software, there could be many instances of a sing= le piece of client software.
    The AS determines which policies apply to a= given client instance, including what it can request and on whose behalf.<= /span>

    Some comments: The above text is stating: "(the client instance, identified by its unique public k= ey)".
    A client instance may use a public key, but that key is not = necessarily unique, in particular when there are multiple ASs.

    [FI] yes, although when possible I would still consider a= better practice to expose a key to a specific AS and not to the entire set= of available ASs.=C2=A0

    Example : a client can be a mobile applicatio= n or a web application (the client software) that requires authorizations f= rom the RO to retrieve content from various protected APIs. The client inst= ance may for instance refer to a specific version of that client software.<= /span>

    <= i>See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance).

    =

    Using the ISO style for definitions, I = propose:

    Client: application used = by an end-user to interact with an AS or a RS

    Note: a client can be a mobile application or a web application <= /span>[FI] for me th= ose are just examples, because there could me more (ex IoT device)

    [FI] you remove the entire discussion on client = instance / client software, is that on purpose because you think it's n= ot useful/right, or is it because of something else? (maybe add your commen= t of the related issue)=C2=A0 =C2=A0

    =

    = Resource Server (RS)

    Accepts valid access tokens from the client issued by the AS a= nd serves protected resources on behalf of the RO. There could be multiple = RSs protected by the AS that the client may call.

    <= p style=3D"margin-bottom:12.25pt;line-height:150%">Example : a RS is often composed o= f protected APIs that can be consumed by authorized client software.=C2=A0 =

    One = comment: a RO is not necessarily involved. [FI] a bit hard to imagine, there's some = kind of owner. Could you be more explicit?

    Using the ISO style for definitions, I propose:=

    Resource Server (RS): server that accepts valid = access tokens from clients issued by one or more ASs which are used to gran= t or deny some requested operations

    Note: a RS is often composed of protected APIs that can be consumed b= y clients.

    =C2=A0

    Resource Owner (RO)=

    Authorizes the request t= o access a protected resource from the RS to the client. The RO may decide = to remove its consent at any time.

    Note : the RO may be a physical person or may rep= resent an organization.

    =C2=A0

    Two comme= nts: In order to avoid confusion with the end-user consent, the word "= authorization" is being used instead of "consent". <= span style=3D"font-family:Arial,sans-serif;color:red">[FI] ok=C2=A0<= u>

    It should be said that the RO is an o= ptional component.=C2=A0[FI] why? Using the ISO st= yle for definitions, I propose:

    Resource Owner (= RO): physical person acting on its own or representing an organization that= authorizes to clients operations on protected resources from a RS

    Note: The RO is an optional component = that may interact either with one RS or with one or more ASs ,e.g. using an= IS.

    End-user =E2=80=93 th= is was previously Requesting Party RQ

    A physical person that operates and interacts= with the client software.

    Note : the end-user may or may not be the same entity as= the RO.

    The Note is sli= ghtly incorrect. the physical person= may or may not be the same = entity as the RO. [FI] I didn't unders= tand your comment

    Using the ISO style for definitions, I propose:<= /u>

    End-user :=C2=A0 physical perso= n that operates and interacts with the client software

    Note : that physical person may or = may not be the same entity as the RO.

    =C2=A0

    Access Token

    A set of privileges delegated to the client i= nstance for a specific end-user. An access token is created by the AS, cons= umed and verified by the RS, and issued to and carried by the client's = end-user on behalf of the RO. The contents and format of the access token a= re opaque to the client.

    Example : JWT is a commonly used format. <= /u>

    Note 1 : an access token g= enerally has a limited duration, after which it may be refreshed at a regul= ar interval.

    Note 2 : an access token may be revoked at any time by the RO. <= u>

    Note 3 : an access token may act as = a capability or require an additional authentication by binding to a key

    A fundamental point: the t= hird sentence from the definition states: "The contents and format of the access token are opaque to the clie= nt".

    [FI] I'll check your other thr= ead dedicated to that issue=C2=A0

    See my other email sent today about "RS-Token Introspection or= RC-Token Introspection" where I conclude:

    = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For end-users caring about their privacy (or= for systems willing to protect the user's privacy), access tokens shou= ld not be considered
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to be opaque to RCs nor to RSs and ASs shou= ld not support Token Introspection, whether it is RS-Token Introspection or= RC-Token Introspection.

    The example and the other Notes above should be remov= ed. If needed they should be placed in the main body of the document.

    Using the ISO style for definitions, I propose:<= /span>

    Access Token : digitally signed data issued by an Authorization Server (= AS) and consumed by a Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that contains rights and/or attributes granted to a particular end-user=

    =C2=A0<= u>

    Grant

    The process by which the client requests and is given delegated access= to the RS by the AS through the authority of the RO.<= /p>

    Using the I= SO style for definitions, I propose:

    Grant: per= mission given to end-user to use a subset of his rights and/or his attribut= es at a specific time and for a specific duration

    =C2=A0

    Key<= /span>

    A public= cryptographic binding a request to the holder of a private key. Access tok= ens and client instances can be associated with specific keys at a point in= time.

    N= ote : a key can be rotated or revoked by its holder. The protocol supports = the update of the key information.

    "key" is a general term that is we= ll understood and that does not need to be defined. [FI] I really wouldn't bet on th= at. We can reuse an existing definition but it is a central piece so we nee= d to be explicit

    The "def= initions" section is not intended to explain what can be done with the= term that is being defined. [FI] ok we can work on that
    Until the word = "key" is qualified using one or more other terms, this definition= should be removed.

    =C2=A0

    Resource

    A protected API served by the RS= and accessed by the client if and only if access has been granted. Access = to this resource is delegated by the RO as part of the grant process.

    = The second= sentence of the definition is not in accordance with the ISO style or defi= nitions and furthermore this second sentence should be removed since a RO i= s an optional element.

    =C2=A0=

    Using the ISO style for definitions= , I propose: =

    Resource: protected API= served by a RS and accessed by a client, if and only if access is granted = by an access token

    = Subject Information

    Information about a subject (usually a RO) th= at is returned directly to the client from the AS.

    =

    Note : this information needs to be u= nique.

    =C2=A0<= /u>

    This definition exhibits several problems:

    =

    (1) The term "= subject" is not defined.

    (2) The information= that is returned is for an end-user, i= .e. not for "(usually a RO)= ".

    (3) The Note s= tates : "this information needs to be unique". Does it mean uniqu= e for the AS ? globally unique ?

    This definition should be revisited. [FI] I agree (I myself had many qu= estions here)

    Denis

    =C2=A0

    My questions :

    - probably we=E2=80=99d need to define subject

    = Subject= : https://open-measure.atlas= sian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry=

    - might be u= seful to clarify the relationship to what identity providers do=C2=A0

    =C2= =A0

    =C2=A0=

    Cheers

    Fabien

    =C2=A0

    =C2=A0=

    =C2=A0

    =

    =C2=A0<= /u>

    =C2=A0

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

    -- T= XAuth mailing list TXA= uth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000008501ce05b6680c00-- From nobody Mon Dec 14 00:02:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280003A0A42 for ; Mon, 14 Dec 2020 00:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=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 NTG7ReoZKEj5 for ; Mon, 14 Dec 2020 00:02:24 -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 14D073A0A3E for ; Mon, 14 Dec 2020 00:02:24 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id z5so16014077iob.11 for ; Mon, 14 Dec 2020 00:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tOVjKpOszKoT+60bmwc0FFLoe5x/ISj+VSP7amL4w6o=; b=Fpc12WoYH2JjClPB/wsHrbq/mvOcRBq3F2y3sFK8ylePiuYyg4Uqrm8Hjld29pzbi+ fbZ14z8O+XIF+6rAEE/gWvJRpKq3sChd7tHXYRfb0ePeGkLL74hjYAHWrfM4tTGY2qeu 5Sxje2DX1S8i93YDByRCkx1CujYGI5e9W2RiUeQdq1I/zzxkvXEAEdjNH8n9jzeEeh8P o1QEFYxDFJklt7mCa9sJFTp2tLRA3HkOK+fg6vyaImC4JSZ02yu4b5er+4QZQacuo43v rymnWSqWCP15qosj/mHmYeRZF1rdbiXktAuivcWIwSD/BK2IYWmoXQ31ThTkBvlULm6p Xiiw== 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=tOVjKpOszKoT+60bmwc0FFLoe5x/ISj+VSP7amL4w6o=; b=hzgpMQ/rrU3DGcBM94ijNmCi7TYGlajws64/gdrQt4CIpK02bq9nLW+/Af4UXwMstT CFrD2WXehmtbHsjrFA5JTwcMs/2EFUB4m2OQxBeFrpa9XxAWNsZnxvmhI/gNWABW+795 qmka0MqYP84wT6WWxAJoAvUj3C4oUbez9C86p7JYfn4u0mDkV1QjRkJzWOVYgcsdfBTl nQmEjth7AkyibcMmINMLQaEl8BakaI39mx0gL2U4rPGWA47LEpYcOs2AKJ0KoPfBCnYw 7XteTJz9ffeAdtS5jlMO5scmv6bfsEy7vW24wc7pBV2u9z4WNXNJfSkWmVTR5ObHxhDd nsfA== X-Gm-Message-State: AOAM532/5P3AO7B3DMOyS+/ny7No7ZihUTATrXZkEQeDuH3nhlkLF0hA vT1DSBG0KKawUunWQ9OdrBF3Qer4Jiq0UFjOB6Y= X-Google-Smtp-Source: ABdhPJwTJr9mfQEdXJI2c7j90UKePtuAERv4e5yclCeVyKv1adRv7bjbcRz5tjjv3CCACMsxjgeQXKFi6cn/0OMeeS8= X-Received: by 2002:a5e:a916:: with SMTP id c22mr30421038iod.144.1607932943503; Mon, 14 Dec 2020 00:02:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 14 Dec 2020 09:02:12 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="000000000000eb95f805b6680f2d" Archived-At: Subject: Re: [GNAP] client definition 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, 14 Dec 2020 08:02:26 -0000 --000000000000eb95f805b6680f2d Content-Type: text/plain; charset="UTF-8" Ok, thanks for the clarification. I'll try to think of a new definition with that in mind. On Sun, Dec 13, 2020 at 11:24 PM Tom Jones wrote: > It could be the RO or a guardian for the RO so user is the right term. > Peace ..tom > > > On Sun, Dec 13, 2020 at 10:42 AM Fabien Imbault > wrote: > >> Hi, >> >> Thanks for the feedback. Highly use case specific seems a bit of an >> overstatement, I would say it is the most common case. But I get your point. >> We've tried to be more specific on end-user vs RO. In your proposal I >> guess the user you're referring to is the RO. >> >> I find the suggested definition a bit convoluted, let's think about it a >> bit more. >> >> Cheers >> Fabien >> >> >> On Sun, Dec 13, 2020 at 7:04 PM Tom Jones >> wrote: >> >>> This definition is highly use case specific. It leaves out the >>> possibility of (eg) a self-issued identifier where the RP displays a >>> request to the user on a web page, the user clicks the button and the >>> result is that a wallet on the user's device acting as the AS sends an >>> access token to the RP (which is typically the client in an OAUTH sense.) >>> The underlined part is often incorrect. >>> >>> Client >>> >>> - Definition: application *used by an end-user* to interact with an >>> AS or a RS >>> >>> suggestion: Client, an application that desires to get access privileges >>> from a user to resources on an RS, possibly by way of an AS. >>> >>> Peace ..tom >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000eb95f805b6680f2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ok, thanks for the clarification.=C2=A0
    I'll t= ry to think of a new definition with that in mind.

    On Sun, Dec 13, 202= 0 at 11:24 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    It could be the RO or a guard= ian for the RO so user is the right term.
    Peace ..tom

    On Sun, = Dec 13, 2020 at 10:42 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    <= /div>
    Hi,= =C2=A0

    Thanks for the feedback. Highly use case specific= seems a bit of an overstatement, I would say it is the=C2=A0most common ca= se. But I get your point.
    We've tried to be more specific on = end-user=C2=A0vs RO. In your proposal I guess the user you're referring= to is the RO.=C2=A0

    I find the suggested definiti= on a bit convoluted, let's think about it a bit more.=C2=A0
    <= br>
    Cheers
    Fabien


    On Sun, Dec 13, 2= 020 at 7:04 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    This defin= ition is highly use case specific. It leaves out the possibility of (eg) a = self-issued identifier where the RP displays a request to the user on a web= page, the user clicks the button and the result is that a wallet on the us= er's device acting as the AS sends an access token to the RP (which is = typically the client in an OAUTH sense.) The underlined part is often incor= rect.

    Clien= t

    • Definition: application used by an end-user to interact with an= AS or a RS
    suggestion: Client, an application = that desires to get access privileges from a user to resources on an RS, po= ssibly by way of an AS.

    Peace ..tom
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000eb95f805b6680f2d-- From nobody Mon Dec 14 00:52:13 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432623A0D8B for ; Mon, 14 Dec 2020 00:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 152g_l398NiB for ; Mon, 14 Dec 2020 00:52:09 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BC43A0D7C for ; Mon, 14 Dec 2020 00:52:08 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 23so28140367lfg.10 for ; Mon, 14 Dec 2020 00:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0GWvg5+pwZ6wb32iCsK6RFI4zCPWqs67qMGDrETYkSk=; b=M32B6ULmhk6/tr/CybuwY1mxoNatXmsB8mG8fSMqJp1NiJwd7FtZE+NxZ4Z2n/BkrE ftMMpRe8XFZzQ72n+Y3PR1agm+14JR1VEAHJwLDTgRV+VFrOjdf9pvHm73Lmc1TAGyZD P0vwSy/C7VeZbDRf1oeLMGmP3fxIdsw52ScXYQTCmadFea4fiEZa2Y2v0AWB2yPxxUOA g1fI8GbABoSgAely9vJxzMTQnC1KywLjuVD44XusQQzFSQqfLdrfgbe11hBPUtGqg3fF xRDGDIwZeih44TT043obLo9GgmYMjSQPp6a1UA6AtKX3vqzk0Cqw290PJHyfvF9iYubI P+Qg== 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=0GWvg5+pwZ6wb32iCsK6RFI4zCPWqs67qMGDrETYkSk=; b=n13TeytEoxarpOFU73Le0Ryp8yBv31F3ix3Z+QpEz9Llu70Kb5Vop8Xkio3/SvwGu+ MPlofAPUhMqjBNHg2kK4B00Us51F0SWUxpDOUWME72jsgMT4Te12OXd6YlC4rO3mB74l FjfuYerbCD3bsiU/2p8kPbHt6eyxSplH3Ql7tc9XBWmpn3bfJf1O1rjG2n2C0mVf0SFF 5A0uSy3M4DcsJswSNkZ5JIGKPnhg59NfVxXx+/3ze84fuT8WOYVLuLtSvpp15uNS/MnS wchIhW6vdaXeLeaAXALepj4OJWDcf82hRo03vn+tLp5n/q92L8OtpBz/IU7GfH8AblDK Kctw== X-Gm-Message-State: AOAM530gwWGO/jlHxBmy9PgM94TmNyr69wrZDTxcdAQh0EfrtIXd3j+v U/524w0rHWkRxcHsgbZhFQsov5RhL/JW4E9bfrqM9A== X-Google-Smtp-Source: ABdhPJzPm7/3cvRWr2jKoxZTLyMiWocfY4EUCtg/VIUxOya4MvFPxmBkvsaEbJMP1jm8cae0z4//CecvqZZzXNCriDM= X-Received: by 2002:a19:4ad8:: with SMTP id x207mr10107494lfa.9.1607935926944; Mon, 14 Dec 2020 00:52:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jim Willeke Date: Mon, 14 Dec 2020 03:51:30 -0500 Message-ID: To: Tom Jones Cc: Fabien Imbault , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000bf5e2b05b668c1a3" Archived-At: Subject: Re: [GNAP] physical person 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, 14 Dec 2020 08:52:11 -0000 --000000000000bf5e2b05b668c1a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I agree. -- -jim Jim Willeke On Sun, Dec 13, 2020 at 5:31 PM Tom Jones wrote: > agree w/ Fabien on that point. My own preference would be to call the RO > an entity, which means a named object. > Peace ..tom > > > On Sun, Dec 13, 2020 at 12:23 PM Fabien Imbault > wrote: > >> Hi, >> >> Yes. >> >> For end user at least, we wanted to convey that it is a real person. >> >> The case is different for the RO, indeed here person would be enough I >> believe. >> >> Fabien >> >> >> Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke a = =C3=A9crit : >> >>> A natural person is usually implied to be a Human Being. >>> As in jurisprudence, fundamental human rights are implicitly granted >>> only to Natural Persons. >>> >>> A person or entity seems to be more appropriate. >>> >>> -- >>> -jim >>> Jim Willeke >>> >>> >>> On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault >>> wrote: >>> >>>> Hi, >>>> >>>> Wasn't thinking about that, but yes. >>>> Natural person would be good. I change it in the wiki. >>>> >>>> Thxs >>>> Fabien >>>> >>>> On Sun, Dec 13, 2020 at 7:07 PM Tom Jones >>>> wrote: >>>> >>>>> I dislike this. A robot can be a physical person. What's wrong with >>>>> natural person that others use? >>>>> Peace ..tom >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000bf5e2b05b668c1a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes, I agree.=C2=A0
    --
    -jim
    Jim Willeke

    <= /div>
    O= n Sun, Dec 13, 2020 at 5:31 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    agree w/ Fab= ien on that point.=C2=A0 My own preference would be to call the RO an entit= y, which means a named object.
    Peace ..tom


    On Sun, Dec 13, 202= 0 at 12:23 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi,

    Yes.=C2=A0

    For end user at least, we wanted to convey = that it is a real person.=C2=A0

    The case is different for the RO, indeed here person would be eno= ugh I believe.=C2=A0

    Fab= ien


    Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke <= ;jim@willeke.com&g= t; a =C3=A9crit=C2=A0:
    A natural person is usually implied to be a Human B= eing.
    As in jurisprudence, fu= ndamental human rights are implicitly granted only to Natural Persons.

    A person or entity seems to be more appr= opriate.

    --
    -jim
    Jim Willeke


    <= div class=3D"gmail_quote">
    On Sun, Dec= 13, 2020 at 1:44 PM Fabien Imbault <fabien.imbault@gmail.com&= gt; wrote:
    Hi,=C2=A0

    Wasn't thinking=C2=A0about tha= t, but yes.
    Natural person would be good. I change it in the wiki= .=C2=A0

    Thxs
    Fabien

    On Sun, Dec 13,= 2020 at 7:07 PM Tom Jones <thomasclinganjones@gmail.com&g= t; wrote:
    I dislike this. A ro= bot can be a physical person. What's wrong with natural person that oth= ers use?
    Peace ..tom
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000bf5e2b05b668c1a3-- From nobody Mon Dec 14 00:57:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0523A0DBA for ; Mon, 14 Dec 2020 00:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LNkdsc1e0wZ for ; Mon, 14 Dec 2020 00:57:50 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8ECA3A0DA0 for ; Mon, 14 Dec 2020 00:57:50 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id i18so16158813ioa.1 for ; Mon, 14 Dec 2020 00:57: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=nqk9HPgUay8JWRjC0l3ucSPYCEpBxh3dWhs7BF6jxY4=; b=Cya8vHaVaesu8va9Q9RVddB9kFjnzVIFeRABGE+Rs8I+gFHS1eS423cmgrdcIUffn4 nV9KFuB0FxrAlj5ETmBee6tPjlH6CJ5kKSU7IbMrqhW9MftmQm+m/vrzrB2hAux0mGOO 7lX6zL15fCYWnxMMch9T5N7YDpY7+rV2j00PTWXUYog9mNPXv1qLqN/pr2KxmFTam5A8 NPY7pO55mLoOdBuUBE2iJQbb683mUx0GEpni2hbHm45AGvOGD53uol673Hb6S+VZl4oT XqKLQfGaE2BC2dSGx+Ap9tV50oxRwgdX1uyZq5hs6ZwF3qYvM9E+0UyhIj0F27gZB8/0 nASw== 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=nqk9HPgUay8JWRjC0l3ucSPYCEpBxh3dWhs7BF6jxY4=; b=X9LUnsFkIg+4PxF+UBr4UVUWuVH/OQy/X141bDJDSalFN3RZ/020Jx2xJh/OZ5eFM8 BreVkFJxwlpPrFKJcRrHkWrM9Ul5nwPR0CPa8Qk2TEaVFJNyymN1cHljZoVbTXqJw3VC Y+BzttxRsathdgZAFIjHZeKRZSBX/yfC0WuEgQu4FKeNJDasEowd69mwJOdEBYw5kHS9 Kj2ZcSZe6a8/0I0VmLfmONPM9zHMebUNrNHK7+vXo9MjCvOm25fAkjDxCjbM4sGYP0nU 0wN814EkclCVEiRlZ3ndfghOcOtLpH3J3Zn024Jzqf+8Qb7ivzwbX4tRqrw9ni53oneW DpTw== X-Gm-Message-State: AOAM532apOa5mQ/rJcKDNwSOPyWoA6nMHvHsDB1iVbAMh4zaVRamb9LL HhEAA3SWwkg+L6+nEYyx19im8tY1vLmtygA9q+wqGSdHhLJCh9vJ X-Google-Smtp-Source: ABdhPJzxFSzeQyW0qJDWg2oc/mZxLVqwAPVIqDmFNogqa3ekPf4IzWWF9HIeOw+yt2/i8lb6disGrIHKmzYBnrke9NQ= X-Received: by 2002:a6b:dd13:: with SMTP id f19mr30892001ioc.74.1607936270081; Mon, 14 Dec 2020 00:57:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 14 Dec 2020 09:57:39 +0100 Message-ID: To: Jim Willeke Cc: Tom Jones , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000033258005b668d6e1" Archived-At: Subject: Re: [GNAP] physical person 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, 14 Dec 2020 08:57:53 -0000 --00000000000033258005b668d6e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your inputs, we can try to update the definition of RO using "entity". Currently we have : person acting on its own or representing an organization, that may grant privileges on resources he has authority upon Alternative 1 : personal or organizational entity that may grant privileges on resources it has authority upon Alternative 2 : entity that may grant privileges on resources it has authority upon What do you think? Cheers Fabien On Mon, Dec 14, 2020 at 9:52 AM Jim Willeke wrote: > Yes, I agree. > -- > -jim > Jim Willeke > > > On Sun, Dec 13, 2020 at 5:31 PM Tom Jones > wrote: > >> agree w/ Fabien on that point. My own preference would be to call the R= O >> an entity, which means a named object. >> Peace ..tom >> >> >> On Sun, Dec 13, 2020 at 12:23 PM Fabien Imbault >> wrote: >> >>> Hi, >>> >>> Yes. >>> >>> For end user at least, we wanted to convey that it is a real person. >>> >>> The case is different for the RO, indeed here person would be enough I >>> believe. >>> >>> Fabien >>> >>> >>> Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke a= =C3=A9crit : >>> >>>> A natural person is usually implied to be a Human Being. >>>> As in jurisprudence, fundamental human rights are implicitly granted >>>> only to Natural Persons. >>>> >>>> A person or entity seems to be more appropriate. >>>> >>>> -- >>>> -jim >>>> Jim Willeke >>>> >>>> >>>> On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Wasn't thinking about that, but yes. >>>>> Natural person would be good. I change it in the wiki. >>>>> >>>>> Thxs >>>>> Fabien >>>>> >>>>> On Sun, Dec 13, 2020 at 7:07 PM Tom Jones < >>>>> thomasclinganjones@gmail.com> wrote: >>>>> >>>>>> I dislike this. A robot can be a physical person. What's wrong with >>>>>> natural person that others use? >>>>>> Peace ..tom >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --00000000000033258005b668d6e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for your inputs, we can try to update the definitio= n of RO using=C2=A0"entity".=C2=A0

    Currently w= e have : person acting on its own or representing an organization, that may= grant privileges on resources he has authority upon

    Alternative 1 : personal or organizational entity that may grant privile= ges on resources it has authority upon
    Alternative 2 : entity tha= t may grant privileges on resources it has authority upon
    What do you think?=C2=A0

    Cheers
    <= div>Fabien
    On Mon, Dec 14, 2020 at 9:52 AM Jim Willeke <jim@willeke.com> wrote:
    Yes, I agree.=C2=A0=
    --
    -jim
    Jim Willeke


    On Sun, Dec 13, 2020 at= 5:31 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    agree w/ Fabien = on that point.=C2=A0 My own preference would be to call the RO an entity, w= hich means a named object.
    Peace ..tom


    On Sun, Dec 13, 2020= at 12:23 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi,
    =

    Yes.=C2=A0

    For end user at least, we wanted to convey t= hat it is a real person.=C2=A0

    The case is different for the RO, indeed here person would be enough= I believe.=C2=A0

    Fabien=


    Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke <jim@willeke.com> = a =C3=A9crit=C2=A0:
    A natural person is usually implied to be a Human Bein= g.
    As in jurisprudence, funda= mental human rights are implicitly granted only to Natural Persons.<= /div>

    A person or entity seems to be more appropr= iate.

    --
    -jim
    Jim Willeke


    On Sun, Dec = 13, 2020 at 1:44 PM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
    Hi,=C2=A0

    Wasn't thinking=C2=A0about that= , but yes.
    Natural person would be good. I change it in the wiki.= =C2=A0

    Thxs
    Fabien

    On Sun, Dec 13, = 2020 at 7:07 PM Tom Jones <thomasclinganjones@gmail.com>= ; wrote:
    I dislike this. A rob= ot can be a physical person. What's wrong with natural person that othe= rs use?
    Peace ..tom
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --00000000000033258005b668d6e1-- From nobody Mon Dec 14 01:56:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB8E3A0E9F for ; Mon, 14 Dec 2020 01:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj0HaXKRlLuC for ; Mon, 14 Dec 2020 01:56:36 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287713A0E8F for ; Mon, 14 Dec 2020 01:56:36 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id n9so4289603ili.0 for ; Mon, 14 Dec 2020 01:56:36 -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=DznQZP6rfM0qo0n6PdYsFZEG18yuWgSpYkcUJG54rFI=; b=A/IvUJsgv1YwacILgfydRy9qYbOv6mMzPpjuE85k6LtbdIVDDRnQ0OHzqixS1bdUz7 NJBlcjfRR9iOXfnYC3a5lSlHPMfIraY4W7HQWIC4fUCzpuWEzaifm6pjJDopdFbHGYfv C1HMXWhyZP+9lcYYyhAxB03lsIzAG9qKMx8xce9Dim0YFxBoyM+vJO2GqLLvzli2bKBW k6SZ2Np3XASEwheTqckT2w8UEGhRI268/vigwQcRHJ+DIjJ7kx0W5bQSnnEmM/q4IgwS XUQRzdn1IP7D6BHZeC+O0BDZFPjd9vDSlXe2e+bsYFH5PJW2OrnMHFgEip776Eg+TN+6 KqKw== 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=DznQZP6rfM0qo0n6PdYsFZEG18yuWgSpYkcUJG54rFI=; b=YLXkvHsX6bBEp25oldXx2fafRTp55OkW6ZS+1+hJOjDMRzLjnpYh9FZif1dkzquIqA uFyb/o67YCdC7/LYIh7X/5hW3psh04GfWf4RcOaQAkxmMd5p81/XkMKNFK/dC3Kg5zQt 60wCDM29s6g/qZjEZe81m3IeXR6Xaa09vfVIHRG5h9Gfg3sNzlupax/6jPmZxuvYBhYu fNaaUCpuwOTAviIaoSmfjOuVhClyEsX+uJN27XX7ZOrGf8XP9qUskMOrS6IMpUddi7vw Ovpwhb2grd7yr2RZPN5baIn/wX+7BmplCHqKNst/EWa4nyxHYy2tQN6HNQfpsX/iUEzB ym+w== X-Gm-Message-State: AOAM532NZmAa83OBdZRorXFOlbwmMTfrE/aJJbS7GSZNzvr13ZlClOKz I6BVs3UwJa4+IQRlX0LM+1ie2N+1kI0WPxljqSpUJbvYTIyFPEy1 X-Google-Smtp-Source: ABdhPJzruEO0vgBCM+xKfczMATir/HGzptipFbjaoOd04DPKFWDLqrUhQfyPCbKfD7M8YcRqycuLJNT6NGbr7ZFtqzk= X-Received: by 2002:a92:aa4c:: with SMTP id j73mr33034164ili.123.1607939795403; Mon, 14 Dec 2020 01:56:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 14 Dec 2020 10:56:24 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="0000000000005348cb05b669a81c" Archived-At: Subject: Re: [GNAP] client definition 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, 14 Dec 2020 09:56:41 -0000 --0000000000005348cb05b669a81c Content-Type: text/plain; charset="UTF-8" I feel that putting user or end-user into the definition might do more harm than good. my suggestion: application that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs. On Mon, Dec 14, 2020 at 9:02 AM Fabien Imbault wrote: > Ok, thanks for the clarification. > I'll try to think of a new definition with that in mind. > > On Sun, Dec 13, 2020 at 11:24 PM Tom Jones > wrote: > >> It could be the RO or a guardian for the RO so user is the right term. >> Peace ..tom >> >> >> On Sun, Dec 13, 2020 at 10:42 AM Fabien Imbault >> wrote: >> >>> Hi, >>> >>> Thanks for the feedback. Highly use case specific seems a bit of an >>> overstatement, I would say it is the most common case. But I get your point. >>> We've tried to be more specific on end-user vs RO. In your proposal I >>> guess the user you're referring to is the RO. >>> >>> I find the suggested definition a bit convoluted, let's think about it a >>> bit more. >>> >>> Cheers >>> Fabien >>> >>> >>> On Sun, Dec 13, 2020 at 7:04 PM Tom Jones >>> wrote: >>> >>>> This definition is highly use case specific. It leaves out the >>>> possibility of (eg) a self-issued identifier where the RP displays a >>>> request to the user on a web page, the user clicks the button and the >>>> result is that a wallet on the user's device acting as the AS sends an >>>> access token to the RP (which is typically the client in an OAUTH sense.) >>>> The underlined part is often incorrect. >>>> >>>> Client >>>> >>>> - Definition: application *used by an end-user* to interact with an >>>> AS or a RS >>>> >>>> suggestion: Client, an application that desires to get access >>>> privileges from a user to resources on an RS, possibly by way of an AS. >>>> >>>> Peace ..tom >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --0000000000005348cb05b669a81c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I feel that putting user or end-user=C2=A0into=C2=A0t= he definition might do more harm than good.=C2=A0

    my su= ggestion:=C2=A0

    On Mon, Dec 14, 2020 at 9:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok, th= anks for the clarification.=C2=A0
    I'll try to think of a new de= finition with that in mind.

    On Sun, Dec 13, 2020 at 11:24 PM Tom Jones= <thom= asclinganjones@gmail.com> wrote:
    It could be the RO or a guardian f= or the RO so user is the right term.
    Peace ..tom


    On Sun, Dec 1= 3, 2020 at 10:42 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    =
    Hi,=C2= =A0

    Thanks for the feedback. Highly use case specific se= ems a bit of an overstatement, I would say it is the=C2=A0most common case.= But I get your point.
    We've tried to be more specific on end= -user=C2=A0vs RO. In your proposal I guess the user you're referring to= is the RO.=C2=A0

    I find the suggested definition = a bit convoluted, let's think about it a bit more.=C2=A0

    =
    Cheers
    Fabien


    On Sun, Dec 13, 2020= at 7:04 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    This definiti= on is highly use case specific. It leaves out the possibility of (eg) a sel= f-issued identifier where the RP displays a request to the user on a web pa= ge, the user clicks the button and the result is that a wallet on the user&= #39;s device acting as the AS sends an access token to the RP (which is typ= ically the client in an OAUTH sense.) The underlined part is often incorrec= t.

    Client
    • Definition: application used by an end-user to interact with an AS= or a RS
    suggestion: Client, an application tha= t desires to get access privileges from a user to resources on an RS, possi= bly by way of an AS.

    Peace ..tom

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000005348cb05b669a81c-- From nobody Mon Dec 14 06:55:55 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65253A11DB for ; Mon, 14 Dec 2020 06:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.006 X-Spam-Level: X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeLnNczapzlR for ; Mon, 14 Dec 2020 06:55:52 -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 8CB2F3A11E4 for ; Mon, 14 Dec 2020 06:55:29 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BEEtQB6017644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2020 09:55:27 -0500 From: Justin Richer Message-Id: <999837CF-DF6F-4189-A5B1-716F0588D13A@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1ABFAD2-266E-4B45-BC67-191F65796019" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 14 Dec 2020 09:55:26 -0500 In-Reply-To: Cc: Tom Jones , txauth gnap To: Fabien Imbault References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] client definition 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, 14 Dec 2020 14:55:54 -0000 --Apple-Mail=_A1ABFAD2-266E-4B45-BC67-191F65796019 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think it=E2=80=99s helpful for the definition to go in this direction.=20= I do want to push back on it being use case specific though =E2=80=94 we = are in fact trying to capture these roles more generally by framing them = with the relationships between the roles as the primary driver. The = negotiation with the AS (as a role) starts with an HTTP request, but = from there the protocol is designed to allow branching off to lots of = different models if the client supports it. The AS as a role could be = fulfilled by several distributed entities, including items running on = the user=E2=80=99s device. There are a lot of things that can be = supported from that model, and it=E2=80=99s my belief that the = self-issued model you=E2=80=99re talking about can layer onto this.=20 =E2=80=94 Justin > On Dec 14, 2020, at 4:56 AM, Fabien Imbault = wrote: >=20 > I feel that putting user or end-user into the definition might do more = harm than good.=20 >=20 > my suggestion:=20 >=20 > application that consumes resources from one or several RSs, possibly = requiring a negotiation of access privileges with one or several ASs. >=20 > On Mon, Dec 14, 2020 at 9:02 AM Fabien Imbault = > wrote: > Ok, thanks for the clarification.=20 > I'll try to think of a new definition with that in mind. >=20 > On Sun, Dec 13, 2020 at 11:24 PM Tom Jones = > = wrote: > It could be the RO or a guardian for the RO so user is the right term. > Peace ..tom >=20 >=20 > On Sun, Dec 13, 2020 at 10:42 AM Fabien Imbault = > wrote: > Hi,=20 >=20 > Thanks for the feedback. Highly use case specific seems a bit of an = overstatement, I would say it is the most common case. But I get your = point. > We've tried to be more specific on end-user vs RO. In your proposal I = guess the user you're referring to is the RO.=20 >=20 > I find the suggested definition a bit convoluted, let's think about it = a bit more.=20 >=20 > Cheers > Fabien >=20 >=20 > On Sun, Dec 13, 2020 at 7:04 PM Tom Jones = > = wrote: > This definition is highly use case specific. It leaves out the = possibility of (eg) a self-issued identifier where the RP displays a = request to the user on a web page, the user clicks the button and the = result is that a wallet on the user's device acting as the AS sends an = access token to the RP (which is typically the client in an OAUTH = sense.) The underlined part is often incorrect. >=20 > Client >=20 > Definition: application used by an end-user to interact with an AS or = a RS > suggestion: Client, an application that desires to get access = privileges from a user to resources on an RS, possibly by way of an AS. >=20 > Peace ..tom > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_A1ABFAD2-266E-4B45-BC67-191F65796019 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think it=E2=80=99s helpful for the definition to go in this = direction. 

    I = do want to push back on it being use case specific though =E2=80=94 we = are in fact trying to capture these roles more generally by framing them = with the relationships between the roles as the primary driver. The = negotiation with the AS (as a role) starts with an HTTP request, but = from there the protocol is designed to allow branching off to lots of = different models if the client supports it. The AS as a role could be = fulfilled by several distributed entities, including items running on = the user=E2=80=99s device. There are a lot of things that can be = supported from that model, and it=E2=80=99s my belief that the = self-issued model you=E2=80=99re talking about can layer onto = this. 

     =E2=80=94 Justin

    On Dec = 14, 2020, at 4:56 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    I feel that = putting user or end-user into the definition might do more = harm than good. 

    my = suggestion: 

    application that consumes resources from one or several RSs, = possibly requiring a negotiation of access privileges with one or = several ASs.

    On Mon, Dec = 14, 2020 at 9:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Ok, = thanks for the clarification. 
    I'll = try to think of a new definition with that in mind.

    On Sun, Dec 13, 2020 at 11:24 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    It could = be the RO or a guardian for the RO so user is the right term.
    Peace = ..tom


    On Sun, Dec = 13, 2020 at 10:42 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi, 

    Thanks for the feedback. Highly use case specific seems a bit = of an overstatement, I would say it is the most common case. But I = get your point.
    We've tried to be more specific on = end-user vs RO. In your proposal I guess the user you're referring = to is the RO. 

    I find the suggested definition a bit convoluted, let's think = about it a bit more. 

    Cheers
    Fabien


    On Sun, Dec 13, 2020 at 7:04 PM Tom = Jones <thomasclinganjones@gmail.com> = wrote:
    This = definition is highly use case specific. It leaves out the possibility of = (eg) a self-issued identifier where the RP displays a request to the = user on a web page, the user clicks the button and the result is that a = wallet on the user's device acting as the AS sends an access token to = the RP (which is typically the client in an OAUTH sense.) The underlined = part is often incorrect.

    Client

    • Definition: application used by an end-user to interact with an AS or a = RS
    suggestion: Client, an application that desires to get access = privileges from a user to resources on an RS, possibly by way of an = AS.

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

    = --Apple-Mail=_A1ABFAD2-266E-4B45-BC67-191F65796019-- From nobody Mon Dec 14 07:54:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52DE3A0E6E for ; Mon, 14 Dec 2020 07:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj1uZXvyPnLa for ; Mon, 14 Dec 2020 07:54:06 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5663A1200 for ; Mon, 14 Dec 2020 07:53:36 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id 9so12503239oiq.3 for ; Mon, 14 Dec 2020 07:53:36 -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=bRMPZqNveE34G5xfJl3FJyI1PWG/0XeYJ9vqqK++C5I=; b=bPnDfd+MyJ/yfEd9gUg9+5vht3RLrGs/IW5f8borw0Dc2WTpkuoBcMPPLuTSVkyTKk w0RIA3E+xu8joqaDLDxQushXXfOj1QpqKYwGkHL52pLV1EtfaYWMK8MPLeaBu1fQ5yu4 43oWAsvpanQnusNDCAldoj+/Xtx0JwrKgEtxrAo4eBCMlZKjdWYSwmTteX7Fwbgqnpbk r+LHY0vtudUickxd5HXgYHb+rK6j4PU6nKwcpYNv1LFJ4CnM45SYdJH/tud1Fk7rmD+z PuGksGRYxy8cpItVPRuxUdhs0Rn6Q0ZvUU/ASBLBjIWZSTTgQDxkggiJJjgiuu45QVpc 3gPA== 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=bRMPZqNveE34G5xfJl3FJyI1PWG/0XeYJ9vqqK++C5I=; b=TpSaEYtM8WHiZFW+pAma7znjU3+t1j0Y6SE96+pVX/dD3IKyGiSB6Pgk34APIPOsIp f2oE2plaE6DPB0Uqmg7Lhf5ucuWFHPKQg0x0SvDWScBeYHJ1o5d151rPfSOys0DX/Hhw jlB7FnOzqJbjBLX3ou6m20MtYdZ3yNsnNQMB9kypQnMyJlhD+Z8rP2qWWs7E+MdGzhaP Y/wUFeCuN/tHW/oJTTo9xLAQjlrgZHNFsqynxAn13uNcMinrpYDHCSU+FRkr+1AIwenn 06K3Bov4ElcNxn4w5uKxheSV0AViJXgZmqaVZNplVEVl+tv5U5WM4bDNcsWniL6ewxf4 g+Pg== X-Gm-Message-State: AOAM533iKccWDsKBmA6CiekKbF8A32PPc6n/ogxnK1oBShDKK37ukOAL 8Qe95+vOYI4ZsdBeqW5Hg7YC1gP8GdrJxzw0YtE= X-Google-Smtp-Source: ABdhPJxNg0oUv5ypkyNwIcvG/ajTUpO/YqKpAeE0gzZOQ6fiuq6lCZEkFkOd4QLfr1LhNunp0rjO5FjLysh55oMIIYI= X-Received: by 2002:aca:1109:: with SMTP id 9mr19270471oir.131.1607961215896; Mon, 14 Dec 2020 07:53:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Mon, 14 Dec 2020 07:53:22 -0800 Message-ID: To: Fabien Imbault Cc: Jim Willeke , GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000016126705b66ea58c" Archived-At: Subject: Re: [GNAP] physical person 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, 14 Dec 2020 15:54:08 -0000 --00000000000016126705b66ea58c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Either sounds good to me. thx ..Tom (mobile) On Mon, Dec 14, 2020, 12:57 AM Fabien Imbault wrote: > Thanks for your inputs, we can try to update the definition of RO > using "entity". > > Currently we have : person acting on its own or representing an > organization, that may grant privileges on resources he has authority upo= n > > Alternative 1 : personal or organizational entity that may grant > privileges on resources it has authority upon > Alternative 2 : entity that may grant privileges on resources it has > authority upon > > What do you think? > > Cheers > Fabien > > On Mon, Dec 14, 2020 at 9:52 AM Jim Willeke wrote: > >> Yes, I agree. >> -- >> -jim >> Jim Willeke >> >> >> On Sun, Dec 13, 2020 at 5:31 PM Tom Jones >> wrote: >> >>> agree w/ Fabien on that point. My own preference would be to call the >>> RO an entity, which means a named object. >>> Peace ..tom >>> >>> >>> On Sun, Dec 13, 2020 at 12:23 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> Yes. >>>> >>>> For end user at least, we wanted to convey that it is a real person. >>>> >>>> The case is different for the RO, indeed here person would be enough I >>>> believe. >>>> >>>> Fabien >>>> >>>> >>>> Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke = a =C3=A9crit : >>>> >>>>> A natural person is usually implied to be a Human Being. >>>>> As in jurisprudence, fundamental human rights are implicitly granted >>>>> only to Natural Persons. >>>>> >>>>> A person or entity seems to be more appropriate. >>>>> >>>>> -- >>>>> -jim >>>>> Jim Willeke >>>>> >>>>> >>>>> On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Wasn't thinking about that, but yes. >>>>>> Natural person would be good. I change it in the wiki. >>>>>> >>>>>> Thxs >>>>>> Fabien >>>>>> >>>>>> On Sun, Dec 13, 2020 at 7:07 PM Tom Jones < >>>>>> thomasclinganjones@gmail.com> wrote: >>>>>> >>>>>>> I dislike this. A robot can be a physical person. What's wrong with >>>>>>> natural person that others use? >>>>>>> Peace ..tom >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --00000000000016126705b66ea58c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Either sounds good to me.

    thx ..Tom (mobile)

    On Mon, Dec 14, 2020, 12:57 AM Fabi= en Imbault <fabien.imbault@g= mail.com> wrote:
    Thanks for your inputs, we can try to update the definition of RO usi= ng=C2=A0"entity".=C2=A0

    Currently we have : pe= rson acting on its own or representing an organization, that may grant priv= ileges on resources he has authority upon

    Alternat= ive 1 : personal or organizational entity that may grant privileges on reso= urces it has authority upon
    Alternative 2 : entity that may grant= privileges on resources it has authority upon

    What do you think?=C2=A0

    Cheers
    Fabien<= /div>

    On Mon, Dec 14, 2020 at 9:52 AM Jim Willeke <jim@willeke.com> w= rote:
    Yes, I agree.=C2=A0
    --
    -jim
    Jim Willeke


    On Sun, Dec 13, 2020 at 5:31 PM Tom Jones <thomasclingan= jones@gmail.com> wrote:
    agree w/ Fabien on that point.=C2=A0 My own= preference would be to call the RO an entity, which means a named object.<= br clear=3D"all">
    Peace ..tom


    On Sun, Dec 13, 2020 at 12:23 PM Fabien Imbault &l= t;fabien.imbault@gmail.com> wrote:
    Hi,

    Yes.=C2=A0

    <= /div>
    For end user at least, we wanted to convey that it i= s a real person.=C2=A0

    T= he case is different for the RO, indeed here person would be enough I belie= ve.=C2=A0

    Fabien

    Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke <jim@willeke.c= om> a =C3=A9crit=C2=A0:
    A natural person is usually implied to be a= Human Being.
    As in jurisprud= ence, fundamental human rights are implicitly granted only to Natural Perso= ns.

    A person or entity seems to be m= ore appropriate.
    =
    --
    -jim
    Jim Willeke


    On = Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    Hi,=C2=A0

    Wasn't thin= king=C2=A0about that, but yes.
    Natural person would be good. I ch= ange it in the wiki.=C2=A0

    Thxs
    Fabien

    On Sun, Dec 13, 2020 at 7:07 PM Tom Jones <thom= asclinganjones@gmail.com> wrote:
    I dislike this. A robot can be a physical person. What's wron= g with natural person that others use?
    Peace ..tom
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --00000000000016126705b66ea58c-- From nobody Mon Dec 14 09:30:22 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5551B3A129C for ; Mon, 14 Dec 2020 09:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nduu3x7dhCK5 for ; Mon, 14 Dec 2020 09:30:19 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8543A1295 for ; Mon, 14 Dec 2020 09:30:19 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id y5so17647313iow.5 for ; Mon, 14 Dec 2020 09:30:19 -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=jIKd3B7hNDEM5jE8NyEUt/BvKHkfzW63yHTIfwz5drM=; b=I6326F+rvvlQEwd/0lVoy1/Cpu3BJkO0+dNfBY3DcnhrbQ6qMHZwCff675gU8HRWkY HjE0p5dmfSdIb8Wdx0WI+vPTib/2OLkkCG5uaEJ0Whc3aLD1eDgkfZMKW5f8qxs3qNrL dzgV2+MhEz/wTq/9Z2MPwr9xWMCB+y0WAJu1h2rKKpcxmQXNawWlBjnbRn9LRrS1Msp3 IDIEcfnInu0W5OKlinfIcUYrKRmGGOc2xOp6ZMKe0fs3VZqa2wrB8EWrMBjxsj1o7HO4 D+FoaA8s07tr/EtqkKOrsf9R14RNS46TKebo1MBBBIpebm9wTDn1G89HoLGbjgb0BrpN ooDA== 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=jIKd3B7hNDEM5jE8NyEUt/BvKHkfzW63yHTIfwz5drM=; b=EKvbveLpJSqfROy7Cal4qofScska3Exr+IdJwMt1eofIZbyqgM577BN+PXfoHg1M8s FOnrEgOn1y2BUZ0HeLp6hz23wtXoEFbT6dwYexjPz3fNlw0H2cwlMDaNyrkLoVWqMwbq mp4gHbpRK/23R1nDKA0BecJlmLAZi+OLwr2qS8W6g4UBrKTZddOCzFPU4wQ/Vo94Q4VT fbp0/eDcWR+galpeniU4Da5VoT9Tf8N2mkAuHSx5kqUjU9fs7lIAHNz0meMPOZsSg7cl h1qAU16SKr1KgS0Ko0kJgmI6BjiGJBuh8+GBE94V6hjuMECLh2g8kwS5Is+15Uy7aZVO uBGQ== X-Gm-Message-State: AOAM531K1QStB5B/LpTFjgEiJmhLx+R6f6cWdDMrey20oZWiP1bVd175 TyQNL8adjdvoTZqnqTLcXIgM4mSWUjDvYyrKxes= X-Google-Smtp-Source: ABdhPJzGTq2aGSXTYD3EcCF9KlMyU1uhXuDphJ06uhUn8iN7dayZNyCamntQkRbYAraSzVexxDedn7Z122eb0Sa/P2Q= X-Received: by 2002:a02:9f8b:: with SMTP id a11mr34891930jam.108.1607967017732; Mon, 14 Dec 2020 09:30:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Mon, 14 Dec 2020 18:30:06 +0100 Message-ID: To: Tom Jones Cc: Jim Willeke , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000e70f6d05b66ffe45" Archived-At: Subject: Re: [GNAP] physical person 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, 14 Dec 2020 17:30:21 -0000 --000000000000e70f6d05b66ffe45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok I've updated the wiki with alternative 1. Cheers Fabien On Mon, Dec 14, 2020 at 4:53 PM Tom Jones wrote: > Either sounds good to me. > > thx ..Tom (mobile) > > On Mon, Dec 14, 2020, 12:57 AM Fabien Imbault > wrote: > >> Thanks for your inputs, we can try to update the definition of RO >> using "entity". >> >> Currently we have : person acting on its own or representing an >> organization, that may grant privileges on resources he has authority up= on >> >> Alternative 1 : personal or organizational entity that may grant >> privileges on resources it has authority upon >> Alternative 2 : entity that may grant privileges on resources it has >> authority upon >> >> What do you think? >> >> Cheers >> Fabien >> >> On Mon, Dec 14, 2020 at 9:52 AM Jim Willeke wrote: >> >>> Yes, I agree. >>> -- >>> -jim >>> Jim Willeke >>> >>> >>> On Sun, Dec 13, 2020 at 5:31 PM Tom Jones >>> wrote: >>> >>>> agree w/ Fabien on that point. My own preference would be to call the >>>> RO an entity, which means a named object. >>>> Peace ..tom >>>> >>>> >>>> On Sun, Dec 13, 2020 at 12:23 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Yes. >>>>> >>>>> For end user at least, we wanted to convey that it is a real person. >>>>> >>>>> The case is different for the RO, indeed here person would be enough = I >>>>> believe. >>>>> >>>>> Fabien >>>>> >>>>> >>>>> Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke = a =C3=A9crit : >>>>> >>>>>> A natural person is usually implied to be a Human Being. >>>>>> As in jurisprudence, fundamental human rights are implicitly granted >>>>>> only to Natural Persons. >>>>>> >>>>>> A person or entity seems to be more appropriate. >>>>>> >>>>>> -- >>>>>> -jim >>>>>> Jim Willeke >>>>>> >>>>>> >>>>>> On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Wasn't thinking about that, but yes. >>>>>>> Natural person would be good. I change it in the wiki. >>>>>>> >>>>>>> Thxs >>>>>>> Fabien >>>>>>> >>>>>>> On Sun, Dec 13, 2020 at 7:07 PM Tom Jones < >>>>>>> thomasclinganjones@gmail.com> wrote: >>>>>>> >>>>>>>> I dislike this. A robot can be a physical person. What's wrong wit= h >>>>>>>> natural person that others use? >>>>>>>> Peace ..tom >>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> --000000000000e70f6d05b66ffe45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ok I've updated the wiki with alternative 1.=C2=A0Cheers
    Fabien

    On Mon, Dec 14, 2020 at 4:53 PM Tom Jones <= ;thomasclinganjones@gmail.c= om> wrote:
    Either sounds good to me.

    thx ..Tom (mobile= )

    On Mon, Dec 14, 2020, 12:57 AM Fabien Imbault <fabien.imbault@gmail.com>= ; wrote:
    Thanks for your inputs, we can try to update the definition of RO= using=C2=A0"entity".=C2=A0

    Currently we have = : person acting on its own or representing an organization, that may grant = privileges on resources he has authority upon

    Alte= rnative 1 : personal or organizational entity that may grant privileges on = resources it has authority upon
    Alternative 2 : entity that may g= rant privileges on resources it has authority upon

    =
    What do you think?=C2=A0

    Cheers
    Fab= ien

    On Mon, Dec 14, 2020 at 9:52 AM Jim Willeke <jim@willeke.com&g= t; wrote:
    Yes, I agree.=C2=A0
    = --
    -jim
    Jim Willeke


    On Sun, Dec 13, 2020 at 5:31 PM Tom Jones <thomasclinga= njones@gmail.com> wrote:
    agree w/ Fabien on that point.=C2=A0 My ow= n preference would be to call the RO an entity, which means a named object.=
    Peace ..tom


    On Sun, Dec 13, 2020 at 12:23 PM Fabien Imbault &= lt;fabien.imbault@gmail.com> wrote:
    Hi,

    Yes.=C2=A0

    <= /div>
    For end user at least, we wanted to convey that it i= s a real person.=C2=A0

    T= he case is different for the RO, indeed here person would be enough I belie= ve.=C2=A0

    Fabien

    Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke <jim@willeke.c= om> a =C3=A9crit=C2=A0:
    A natural person is usually implied to be a= Human Being.
    As in jurisprud= ence, fundamental human rights are implicitly granted only to Natural Perso= ns.

    A person or entity seems to be m= ore appropriate.
    =
    --
    -jim
    Jim Willeke


    On = Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault <fabien.imb= ault@gmail.com> wrote:
    Hi,=C2=A0

    Wasn't thin= king=C2=A0about that, but yes.
    Natural person would be good. I ch= ange it in the wiki.=C2=A0

    Thxs
    Fabien

    On Sun, Dec 13, 2020 at 7:07 PM Tom Jones <thom= asclinganjones@gmail.com> wrote:
    I dislike this. A robot can be a physical person. What's wron= g with natural person that others use?
    Peace ..tom
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --000000000000e70f6d05b66ffe45-- From nobody Mon Dec 14 10:00:40 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7553A0B22 for ; Mon, 14 Dec 2020 10:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVLtUWxzRxFO for ; Mon, 14 Dec 2020 10:00:35 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0397B3A0B17 for ; Mon, 14 Dec 2020 10:00:34 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id a12so32414430lfl.6 for ; Mon, 14 Dec 2020 10:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IU7O9/an3mtsSYBi7ReRMebv0W+fmCJNPYO5wu3gFlU=; b=rlnFD998VeAOnWkDpDC+IWzkAzZ7+FNe1HFjPEQ8H8SiAO2YL3VUMoR20/o6XByHKH 5n0DR+GlewOoTIiuyQXhx/Kogi5+CNaOn3xdr316QrPytKDGXUDmdGBDH7gUkvhgzmcY +GgqWFwNzDbsPN+vOEdollXMJ3L81fm1bCksdZr2hMV4LNHPwNGZNYXNfQzWmc1PSp5I U/nBYBKT9vsGgLiJuSVwjKlE134aFS44FXP+LG74aYgud46rNMYxcDgjnRj4ZdauZXhY +W5bV2WMWHnOSHcFJSVK7WSbbGM9XN+fo0iEhv9cgVaNDQtIwRGjJBp/UYpIRBTDFiJC wmHw== 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=IU7O9/an3mtsSYBi7ReRMebv0W+fmCJNPYO5wu3gFlU=; b=qARe39ZNbbe3mzSrOWfNotOrV2iHp2RxQ8LTgtWtcZNfUgxEVRkMtfWVL9IHG5Liow +NZrB2RREy8v/S8Va/6rwsIn3LOAbrOzTtls3tQPQiKIIyyqVeZ1dPGjar7Vpp+eE8Z5 kWaRE36Hh8EsZ4QsYzw341vq5QIyGpsi1eRZZl8wFuhqhw3CeripL1UAvt+m8B4W3D0t Urv3J6D1btRDFw3eOHOg76g0atl5jN6GWAmn4EtSZdy4qW6yXIpUx/UD9zK93UWnhimh Va4HFf4jZpzzxu+DbJRSQ/k7GT0zidcihcwutTjX3pjF6O3DjyiyAHW9H6Gu6xN7CC1W mkAw== X-Gm-Message-State: AOAM531hmw+Ruo/g5zCGpFdxJvbXPvCtbKx1/uRUEFrAIzn8vfdTlfEa 9W//erxMh9rAHCk7qMVforqIMpdxGTba5aDyZxU= X-Google-Smtp-Source: ABdhPJybwkA5EckzRNv2Xa49pLndnRS8fveItkIY4wVezWE8mONWXHCzKoZ5QaisSxH9Pt2L0yxZZwneAYFd7X/LcxI= X-Received: by 2002:a19:3818:: with SMTP id f24mr7584371lfa.89.1607968832698; Mon, 14 Dec 2020 10:00:32 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 14 Dec 2020 09:59:55 -0800 Message-ID: To: Fabien Imbault Cc: Stephen Moore , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="000000000000153ddb05b6706b5a" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 18:00:39 -0000 --000000000000153ddb05b6706b5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fabien: a discussion would be more productive if you took some time reading what I wrote. I am not suggesting pre-registration be mandatory I am not making blame arguments are trying to start a flamewar -- I am pointing out that a RESTful like pattern is well understood. I am not suggesting we not use cryptographic keys. I am saying having an "access token" in addition to a URI adds complexity to both the client and the AS with little if any value. A URI is all that is needed unless there is a desire to make the AS stateless, or pass context between the AS and another server -- which seems to me of dubious value. That is all that I used in https://github.com/dickhardt/XAuth-poc So far we are discussing the "access token" in abstract terms. Would you describe what would be contained in the "access token"? /Dick =E1=90=A7 On Fri, Dec 11, 2020 at 5:51 PM Fabien Imbault wrote: > Again speaking in my own name here. > > Dick, we know you'd prefer to have a different design, but this PR > shouldn't be about that. > > Back on your 3 items : > > 1) yes we could make pre-register mandatory, but we already decided that > wouldn't be how that would work. We have a client instance that allows a > more generic and flexible pattern (which BTW also allows what you want) > > 2) instead of blame arguments of who's less restful/HATEOAS/whatever that > have the tenancy to flame conversations, I suggest we speak in less > abstract terms and ask ourselves what that means in practice for devs. > Stephen and several others (myself included) have expressed that it > wouldn't be harder to implement, it would even simplify things quite a lo= t. > If you disagree please send us a code sample to really show that point by > example, because that's really not obvious. > > 3) "If someone has the client credentials, they can impersonate the > client, and all bets are off." Are you seriously making this argument? > Because if you have a better proposal than using cryptographic keys, I'm > all hears. You make it look like there's a problem, while in reality we'r= e > only relying on the basic assumption of all modern digital communications= . > > And more importantly you never responded to the issues of how to avoid th= e > security pitfalls of what you proposed. > > Fabien > > > Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = a =C3=A9crit : > >> >> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore wrote: >> >>> But from the spec: >>> " >>> When sending a non-continuation request to the AS, the RC MUST identify >>> itself by including the client field of the request... >>> ... >>> key (object / string) : The public key of the RC to be used in this >>> request as described in {{request-key}}. This field is REQUIRED. >>> ... >>> " >>> >> So on the initial request, the key will be there. >>> >> >> The client field can be an object or a string. If the client is >> pre-registered, then a string could be provided instead of an object. >> >>> >> >>> >>> If you don't have the access token, then how do you differentiate >>> between two requests from the same web application by two different use= rs? >>> Is the web application supposed to have different credentials for every >>> request? >>> >> >> The AS returns a URI for manipulating the request. I would change the >> spec so that each request would have a unique URI. This is the usually >> RESTful pattern that the resource (the grant request) has an URI. >> >> >> >>> So in this case, the easy way out is to pass the access token to the >>> client, who then, as i stated before, treats the continue request as a = RS >>> call (albeit a specialized version of the RS where the RS is the AS) OR= to >>> use the unique URL, >>> but that seems open to a brute force attack by a malicious RC. (What >>> would be the point of that attack, I don't know, I guess if someone had= the >>> client credentials but not any subjects/resources they could try to >>> intercept the grant via continue... I just don't feel right locking thi= ngs >>> down to unique URLs that way.) >>> >> >> If someone has the client credentials, they can impersonate the client, >> and all bets are off. >> >> LOTS of RS servers return a resource specific URL -- my proposal is no >> different. >> >> >> >> >>> -steve >>> >>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt wrote= : >>> >>>> Hi Stephen >>>> >>>> The client is signing the first request. The key *might* be in the >>>> body. The client is signing all the subsequent requests as well. The >>>> "access token" is not needed by the client to prove it is authorized a= s the >>>> client is proving it is the same client again. >>>> >>>> In other words, I don't see the need for an access token, so it does >>>> not need to be put in a URL or an auth header. >>>> >>>> If a developer really, really wants to hand context back to the client >>>> for subsequent calls, they can put it in the URL or some other method. >>>> Putting it in the HTTP Authorization header is confusing because it is= NOT >>>> an access token -- it is the context of the request. >>>> >>>> =E1=90=A7 >>>> >>>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>> wrote: >>>> >>>>> Even though I've only been lightly following things, I feel the need >>>>> to voice my preference as a developer since I will probably someday h= ave to >>>>> either write a RC or RS... >>>>> >>>>> The way I see it is the RC makes the initial request to the AS as par= t >>>>> of this request, it provides it's key in the body... (So no use of th= e >>>>> Authorization header) >>>>> At this point that request, represented by the continue URL + "Access >>>>> Token", from my lazy developer standpoint, is a Resource Endpoint and >>>>> Access Token, and the AS is acting as a specialized RS in this case. >>>>> So my client posts to whatever URL with the 'access token' in the >>>>> authorization header, just like acting on any other resource I have a= token >>>>> for. YES, I get a new token value to use every call, and there is a >>>>> decision point of "Do I have another continue, or do I have a real to= ken >>>>> for the resource..." But the mechanism is the same to me in the clien= t. >>>>> Personally I like that, because if I have an access_token, I already >>>>> think "Put it in the auth header." >>>>> >>>>> So my vote would be +1 for the pull request at this time. >>>>> -steve >>>>> >>>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>> wrote: >>>>> >>>>>> inline ... >>>>>> >>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> Others had already responded to this previous thread, but I wanted >>>>>>> to add a couple points to clarify some things. >>>>>>> >>>>>>> 3) What the client has to do with the "access token" is not the sam= e >>>>>>> as access tokens for an RS. The client gets a new "access token" fo= r each >>>>>>> grant request, and for each API call to the AS, and the client lear= ns it >>>>>>> can not make any more API calls for that specific request when it d= oes not >>>>>>> get an "access token" back. This is a completely different design p= attern >>>>>>> than calling an RS API with an access token, and is a new design pa= ttern >>>>>>> for calling APIs. This adds complexity to the client that it would = not >>>>>>> normally have, and I don't think GNAP is the right place to start a= new >>>>>>> design pattern. >>>>>>> >>>>>>> >>>>>>> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole >>>>>>> point of the design is that the client would be doing the same thin= g with >>>>>>> the access token at the AS that it does with the RS by re-using the= access >>>>>>> token structure. Can you please describe what the differences are, = apart >>>>>>> from the rotation? Presentation of the token and signing of the mes= sage are >>>>>>> identical. >>>>>>> >>>>>> >>>>>> The client is getting the "access token" from its API. It is not >>>>>> using an "access_token" in other API calls to the AS. >>>>>> >>>>>> >>>>>>> >>>>>>> Rotation of the access token and artifacts for ongoing continuation >>>>>>> responses is a separate issue to be discussed: >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>> >>>>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right place= to have >>>>>>> new designs =E2=80=94 not that this is one. >>>>>>> >>>>>> >>>>>> You are proposing a new way for an API to provide context for >>>>>> subsequent API calls. Looks out of scope to me. >>>>>> >>>>>> >>>>>>> >>>>>>> 4) Clients that only want claims from the AS and no access tokens >>>>>>> will be required to support an API calling mechanism they would not= have to >>>>>>> support otherwise. >>>>>>> >>>>>>> >>>>>>> Correct, but the delta between the calls a client would make with >>>>>>> and without an access token is vanishingly small. The client has to= sign >>>>>>> the initial request in some fashion, and it will sign the continuat= ion >>>>>>> request in the same exact fashion, but now include an access token = in that >>>>>>> request. >>>>>>> >>>>>> >>>>>> Per my other point, there is no value to me in my implementations of >>>>>> passing context back and forth between the client and AS -- so it is= extra >>>>>> work providing no value. >>>>>> >>>>>> Also, any client authentication mechanism that wants to use the HTTP >>>>>> Authentication header is precluded from using it. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Clients making a request to an AS and not getting an access token i= s >>>>>>> a new design pattern. I think it has value and should be included, = but >>>>>>> OAuth today shows us the immense value of getting access tokens for= calling >>>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>>> >>>>>>> >>>>>>> 5) If the AS does not provide an "access token", there is no >>>>>>> mechanism for a client to delete the request, as the client is not = allowed >>>>>>> to make a call without an "access token". >>>>>>> >>>>>>> >>>>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then >>>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>>>> is telling this client instance that it can=E2=80=99t do anything e= lse with this >>>>>>> ongoing request. If the AS wants to allow the client to manage it, = it will >>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D f= ield. >>>>>>> >>>>>> >>>>>> There is nuance in that intention. A related concern is that deletin= g >>>>>> a request does not seem like it is a "continue" operation. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> 6) There is no standard identifier for the request. Debugging and >>>>>>> auditing are hampered by the client and AS having no standard way t= o >>>>>>> identifying a request. While one AS may provide a unique URL for ea= ch grant >>>>>>> request, another AS may use a persistent "access token" to identify= the >>>>>>> grant request, and other ASs may issue a new "access token" on each= API >>>>>>> call, providing no persistent identifier for the request. >>>>>>> >>>>>>> >>>>>>> Debugging and auditing this kind of thing are functions of the AS. >>>>>>> How is interoperability harmed by different ASs having different me= thods to >>>>>>> identify their internal data elements? The client doesn=E2=80=99t n= eed any >>>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know th= e next steps for >>>>>>> continuing the negotiation. >>>>>>> >>>>>> >>>>>> Debugging between the client and the AS was what I was referring to. >>>>>> How does a client developer identify the request when communicating = to the >>>>>> AS developer. Seems complicated. >>>>>> >>>>>> =E1=90=A7 >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> =E1=90=A7 >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000153ddb05b6706b5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Fabien: a discussion would be more productive if you took = some time reading what I wrote.

    I am not suggesting pre-= registration be mandatory

    I am not making blame ar= guments are trying to start a flamewar -- I am pointing out that a RESTful = like pattern is well understood.

    I am not suggesti= ng we not use cryptographic keys.


    <= div>So far we are discussing the "access token" in abstract terms= . Would you describe what would be contained in the "access token"= ;?

    /Dick


    <= br>



    3D""=E1=90= =A7

    On Fri, Dec 11, 2020 at 5:51 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Again speaking in my own name here.=C2=A0

    Dick, we know you'd prefer to hav= e a different design, but this PR shouldn't be about that.=C2=A0
    <= div dir=3D"auto">
    Back on your 3 items :

    1) yes we could make pre-regist= er mandatory, but we already decided that wouldn't be how that would wo= rk. We have a client instance that allows a more generic and flexible patte= rn (which BTW also allows what you want)=C2=A0

    <= /div>
    2) instead of blame arguments of who's less rest= ful/HATEOAS/whatever that have the tenancy to flame conversations, I sugges= t we speak in less abstract terms and ask ourselves what that means in prac= tice for devs. Stephen and several others (myself included) have expressed = that it wouldn't be harder to implement, it would even simplify things = quite a lot. If you disagree please send us a code sample to really show th= at point by example, because that's really not obvious.=C2=A0

    3) "If someone has the clien= t credentials, they can impersonate the client, and all bets are off."= Are you seriously making this argument? Because if you have a better propo= sal than using cryptographic keys, I'm all hears. You make it look like= there's a problem, while in reality we're only relying on the basi= c assumption of all modern digital communications.=C2=A0
    =C2=A0
    And more importantly you never responded= to the issues of how to avoid the security pitfalls of what you proposed.= =C2=A0

    Fabien=C2=A0

    Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.= hardt@gmail.com> a =C3=A9crit=C2=A0:

    On Fri, D= ec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com>= ; wrote:
    But from the spec:
    "
    When sending a non-continuation request to the AS= , the RC MUST identify itself by including the=C2=A0client=C2=A0field of the request...
    <= span style=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemF= ont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji= ","Segoe UI Emoji";font-size:16px">...
    key (object / string) : The = public key of the RC to be used in this request as described in {{request-k= ey}}. This field is REQUIRED.=C2=A0
    ...
    "
    So on the initial request, the key will be there.= =C2=A0

    The cli= ent field can be an object or a string. If the client is pre-registered, th= en a string could be provided instead of an object.
    =C2=A0

    <= /span>
    If you don't have the access token, then how do you di= fferentiate between two requests from the same web application by two diffe= rent users? Is the web application supposed to have different credentials f= or every request?

    The AS return= s=C2=A0a URI for manipulating the request. I would change the spec so that = each request would have a unique URI. This is the usually RESTful=C2=A0patt= ern that the resource (the grant request) has an URI.

    <= div>=C2=A0
    So in this case, the easy way out is to pass the access to= ken to the client, who then, as i stated before, treats the continue reques= t as a RS call (albeit=C2=A0a specialized=C2=A0version of the RS where the = RS is the AS) OR to use the unique URL,=C2=A0
    but that seems open= to a brute force attack by a malicious RC. (What would be the point of tha= t attack, I don't know, I guess if someone had the client credentials b= ut not any subjects/resources they could try to intercept the grant via con= tinue... I just don't feel right locking things down to unique URLs tha= t way.)

    If someone has the clie= nt credentials, they can impersonate=C2=A0the client, and all bets are off.=

    LOTS of RS servers return a resource specific URL= -- my proposal is no different.


    = =C2=A0
    -steve

    On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    Hi Stephen

    Th= e client is signing the first request. The key *might* be in the body. The = client is signing all the subsequent requests as well. The "access tok= en" is not needed by the client to prove it is authorized as the clien= t is proving it is the same client again.

    In other= words, I don't see the need for an access token, so it does not need t= o be put in a URL or an auth header.

    If a develope= r really, really wants to hand context back to the client for subsequent ca= lls, they can put it in the URL or some other method. Putting it in the HTT= P Authorization header is confusing because it is NOT an access token -- it= is the context of the request.

    3D""= =E1=90=A7

    On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    Even though I've only be= en lightly following things, I feel the need to voice my preference as a de= veloper since I will probably someday have to either write a RC or RS...=C2= =A0

    The way I see it is the RC makes the initial r= equest to the AS as part of this request, it provides it's key in the b= ody... (So no use of the Authorization header)
    At this point that= request, represented by the continue URL=C2=A0+ "Access Token", = from my lazy developer standpoint, is a Resource Endpoint and Access Token,= and the AS is acting as a specialized RS in this case.
    So my cli= ent posts to whatever URL with the 'access token' in the authorizat= ion header, just like acting on any other resource I have a token for. YES,= I get a new token value to use every call, and there is a decision point o= f "Do I have another continue, or do I have a real token for the resou= rce..." But the mechanism is the same to me in the client.
    P= ersonally I like that, because if I have an access_token, I already think &= quot;Put it in the auth header."=C2=A0

    So my = vote would be=C2=A0+1 for the pull request at this time.
    -steve

    On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.= hardt@gmail.com> wrote:
    inline ...=C2=A0

    =
    On Fri, De= c 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wro= te:
    Others = had already responded to this previous thread, but I wanted to add a couple= points to clarify some things.

    3) W= hat the client has to do with the "access token" is not the same = as access tokens for an RS. The client gets a new "access token" = for each grant request, and for each API call to the AS, and the client lea= rns it can not make any more API calls for that specific request when it do= es not get an "access token" back. This is a completely different= design pattern than calling an RS API with an access token,=C2=A0and is a = new design pattern for calling APIs. This adds complexity to the client tha= t it would not normally have, and I don't think GNAP is the right place= to start a new design pattern.


    <= /div>
    I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole point of the design is that the client would be doing the = same thing with the access token at the AS that it does with the RS by re-u= sing the access token structure. Can you please describe what the differenc= es are, apart from the rotation? Presentation of the token and signing of t= he message are identical.

    The client is getting the "access token" from its API. It is not= using an "access_token" in other API calls to the AS.
    = =C2=A0

    Rotation of the access token and artifacts for ongoing con= tinuation responses is a separate issue to be discussed:=C2=A0https://github.com/ietf-wg-gnap/gnap-core-= protocol/issues/87

    And for what it=E2=80=99s w= orth, GNAP is absolutely the right place to have new designs =E2=80=94 not = that this is one.

    You are= proposing a new way for an API to provide context for subsequent API calls= . Looks out of scope to me.
    =C2=A0

    4) Cl= ients that only want claims from the AS and no access tokens will be requir= ed to support an API calling mechanism they would not have to support other= wise.=C2=A0

    Correct, but the delta be= tween the calls a client would make with and without an access token is van= ishingly small. The client has to sign the initial request in some fashion,= and it will sign the continuation request in the same exact fashion, but n= ow include an access token in that request.=C2=A0

    Per my other point, there is no value to me in my = implementations of passing context back and forth between the client and AS= -- so it is extra work providing no value.

    Also, = any client authentication mechanism=C2=A0that wants to use the HTTP Authent= ication header is precluded from using it.

    =C2=A0<= /div>

    <= /div>
    Clients making a request to an AS and not getting an access token= is a new design pattern. I think it has value and should be included, but = OAuth today shows us the immense value of getting access tokens for calling= APIs, and so we shouldn=E2=80=99t optimize away from that pattern.

    5) If the AS does not provi= de an "access token", there is no mechanism for a client to delet= e the request, as the client is not allowed to make a call without an "= ;access token".

    More properly, i= f the AS does not provide a =E2=80=9Ccontinue=E2=80=9D field then the clien= t can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99s intent= ional. The AS is telling this client instance that it can=E2=80=99t do anyt= hing else with this ongoing request. If the AS wants to allow the client to= manage it, it will include the mechanisms to do so in the =E2=80=9Ccontinu= e=E2=80=9D field.

    There i= s nuance in that intention. A related concern is that deleting a request do= es not seem like it is a "continue" operation.
    =C2=A0


    6) There is no standard identifi= er for the request. Debugging and auditing are hampered by the client and A= S having no standard way to identifying a request. While one AS may provide= a unique URL for each grant request, another AS may use a persistent "= ;access token" to identify the grant request, and other ASs may=C2=A0i= ssue a new "access token" on each API call, providing no persiste= nt identifier for the request.

    Debugging a= nd auditing this kind of thing are functions of the AS. How is interoperabi= lity harmed by different ASs having different methods to identify their int= ernal data elements? The client doesn=E2=80=99t need any knowledge of the A= S=E2=80=99s identifiers, it just needs to know the next steps for continuin= g the negotiation.

    Debugging be= tween the client and the AS was what I was referring to. How does a client = developer identify the request when communicating to the AS developer. Seem= s complicated.
    =C2=A0
    3D""=E1=90=A7
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    3D""=E1=90=A7
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000153ddb05b6706b5a-- From nobody Mon Dec 14 10:50:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4403A149C for ; Mon, 14 Dec 2020 10:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPG8QbmH5nrN for ; Mon, 14 Dec 2020 10:50:26 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 2DCEA3A149A for ; Mon, 14 Dec 2020 10:50:26 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id z136so17921997iof.3 for ; Mon, 14 Dec 2020 10:50:26 -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=5q33Yfee6EJO3FL7I8RQ6SeHwoOa1c3UO90sN2XbE34=; b=TkaG9I0W7ELFtLsMK+gEsRqJFfy6NxiTVZgB0M4w1k4W2Lq7bIz7ifyvE3MlDQJmNT 3Z8YnEDz4DdkXQH8r6yasgfP4YYhZcXzg0auDS5HQkrHPJvWo4bp7x1Q3tag010KC+Z3 XbmylKkMrHw7ZXz2RuaeXJrL3CVAnufG+HZ9EUYkGHuAFScFW7oNF7XjJ89D3GBkESaO us2wblDYqYIIaBmVmZYk/zg3dfUQ34oNtgxGw/au65DxqBNaaQyznclh6SAnYz5N0NMV PN4U3bgBI3URh7/eLsNuYEythbtKNFNLuwxr2NOA1kpv23PYSrpeCwewpc1EbYL/7yHB ZBOg== 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=5q33Yfee6EJO3FL7I8RQ6SeHwoOa1c3UO90sN2XbE34=; b=Kvfim8FNFkLIS3jyJH36lkA2vEgh4rb8MtW6itZrrKzLkgmvZ/gUTUXeWAug52Fc12 KsBJcssv+KRE/gB7dq47ZRbWeiBav1Aq98bXgEoM5AEwVxLHKRVkpW8gw3IMoLGHQRlc e5gorWt5e9of4YOzF6ORPl/uCWly1dPdNIUOTRfOYa2NBC0++c903aLDdeusD8J1OtfT owIcewXFHEWp3PJfLpbedtLZ4uhes200IXlaRqxAE8bW6KP6ebrgacuSv44PuoD+rsbq aQghYlELCAF8Ok948t3yjnivzi97aVvYeq7689coArurkr0aCR0IcbhhsZqJOqV9DBTR u0qg== X-Gm-Message-State: AOAM532rQoFOr3uPJtFK4Phfngmfe4SNy9gZxpWngMFxPzDzNzXuVtkS WlYm3iVjIUQUmTjsjxnNDDEBPZKUy2oyWLr1wZ0= X-Google-Smtp-Source: ABdhPJy2z6xrVvRVUaEvbesrvLPKCtk6swutz8w2q9WORiR1+gvWsgnEp7eMfolw+z35+8K4KIwkBjwiO7Wx3l5GdWA= X-Received: by 2002:a02:9f8b:: with SMTP id a11mr35221838jam.108.1607971825322; Mon, 14 Dec 2020 10:50:25 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 14 Dec 2020 19:50:13 +0100 Message-ID: To: Dick Hardt Cc: Stephen Moore , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="000000000000750fa705b6711d36" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 18:50:29 -0000 --000000000000750fa705b6711d36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Dick, I'm reading what you write. RESTful patterns are well understood, up to a limit. I've seen more debate around what's good and what's not that on any other subject in my entire career. It rarely helps, if ever. Because everyone thinks he applies the concepts correctly anyway. I observe we're going too much around XAuth (to cite you, "That is all that I used in https://github.com/dickhardt/XAuth-poc") vs XYZ vs GNAP, in some fashion, while I'm really hoping we can go forward. I also advise against making personal attacks and would prefer that we'd keep the discussion to technical arguments only. I'm sure we would all benefit from a win win situation, where we try to arbitrate the best possible technical solution that matches the group's goal. Knowing that there are many cases where it's not black and white. If you are able to convince me with your arguments, I'll back your proposal (or any other, for that matter). But we're really not yet there in that specific case. The cookie comparison is far stretched. I don't understand what is complex in having to handle a token. Please note I'm also expecting some feedback on the security model that should be put in place around the URI model that you propose. Then on your last point, I agree with you, we can certainly give an example of access token. I'll get back to you on that. Fabien ps : I'm also open to discuss privately with you on a better way to cooperate in general. On Mon, Dec 14, 2020 at 7:00 PM Dick Hardt wrote: > Fabien: a discussion would be more productive if you took some time > reading what I wrote. > > I am not suggesting pre-registration be mandatory > > I am not making blame arguments are trying to start a flamewar -- I am > pointing out that a RESTful like pattern is well understood. > > I am not suggesting we not use cryptographic keys. > > I am saying having an "access token" in addition to a URI adds complexity > to both the client and the AS with little if any value. A URI is all that > is needed unless there is a desire to make the AS stateless, or pass > context between the AS and another server -- which seems to me of > dubious value. That is all that I used in > https://github.com/dickhardt/XAuth-poc > > So far we are discussing the "access token" in abstract terms. Would you > describe what would be contained in the "access token"? > > /Dick > > > > > > > =E1=90=A7 > > On Fri, Dec 11, 2020 at 5:51 PM Fabien Imbault > wrote: > >> Again speaking in my own name here. >> >> Dick, we know you'd prefer to have a different design, but this PR >> shouldn't be about that. >> >> Back on your 3 items : >> >> 1) yes we could make pre-register mandatory, but we already decided that >> wouldn't be how that would work. We have a client instance that allows a >> more generic and flexible pattern (which BTW also allows what you want) >> >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever tha= t >> have the tenancy to flame conversations, I suggest we speak in less >> abstract terms and ask ourselves what that means in practice for devs. >> Stephen and several others (myself included) have expressed that it >> wouldn't be harder to implement, it would even simplify things quite a l= ot. >> If you disagree please send us a code sample to really show that point b= y >> example, because that's really not obvious. >> >> 3) "If someone has the client credentials, they can impersonate the >> client, and all bets are off." Are you seriously making this argument? >> Because if you have a better proposal than using cryptographic keys, I'm >> all hears. You make it look like there's a problem, while in reality we'= re >> only relying on the basic assumption of all modern digital communication= s. >> >> And more importantly you never responded to the issues of how to avoid >> the security pitfalls of what you proposed. >> >> Fabien >> >> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a =C3=A9crit : >> >>> >>> >>> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore wrote= : >>> >>>> But from the spec: >>>> " >>>> When sending a non-continuation request to the AS, the RC MUST identif= y >>>> itself by including the client field of the request... >>>> ... >>>> key (object / string) : The public key of the RC to be used in this >>>> request as described in {{request-key}}. This field is REQUIRED. >>>> ... >>>> " >>>> >>> So on the initial request, the key will be there. >>>> >>> >>> The client field can be an object or a string. If the client is >>> pre-registered, then a string could be provided instead of an object. >>> >>>> >>> >>>> >>>> If you don't have the access token, then how do you differentiate >>>> between two requests from the same web application by two different us= ers? >>>> Is the web application supposed to have different credentials for ever= y >>>> request? >>>> >>> >>> The AS returns a URI for manipulating the request. I would change the >>> spec so that each request would have a unique URI. This is the usually >>> RESTful pattern that the resource (the grant request) has an URI. >>> >>> >>> >>>> So in this case, the easy way out is to pass the access token to the >>>> client, who then, as i stated before, treats the continue request as a= RS >>>> call (albeit a specialized version of the RS where the RS is the AS) O= R to >>>> use the unique URL, >>>> but that seems open to a brute force attack by a malicious RC. (What >>>> would be the point of that attack, I don't know, I guess if someone ha= d the >>>> client credentials but not any subjects/resources they could try to >>>> intercept the grant via continue... I just don't feel right locking th= ings >>>> down to unique URLs that way.) >>>> >>> >>> If someone has the client credentials, they can impersonate the client, >>> and all bets are off. >>> >>> LOTS of RS servers return a resource specific URL -- my proposal is no >>> different. >>> >>> >>> >>> >>>> -steve >>>> >>>> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>> wrote: >>>> >>>>> Hi Stephen >>>>> >>>>> The client is signing the first request. The key *might* be in the >>>>> body. The client is signing all the subsequent requests as well. The >>>>> "access token" is not needed by the client to prove it is authorized = as the >>>>> client is proving it is the same client again. >>>>> >>>>> In other words, I don't see the need for an access token, so it does >>>>> not need to be put in a URL or an auth header. >>>>> >>>>> If a developer really, really wants to hand context back to the clien= t >>>>> for subsequent calls, they can put it in the URL or some other method= . >>>>> Putting it in the HTTP Authorization header is confusing because it i= s NOT >>>>> an access token -- it is the context of the request. >>>>> >>>>> =E1=90=A7 >>>>> >>>>> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>> wrote: >>>>> >>>>>> Even though I've only been lightly following things, I feel the need >>>>>> to voice my preference as a developer since I will probably someday = have to >>>>>> either write a RC or RS... >>>>>> >>>>>> The way I see it is the RC makes the initial request to the AS as >>>>>> part of this request, it provides it's key in the body... (So no use= of the >>>>>> Authorization header) >>>>>> At this point that request, represented by the continue URL + "Acces= s >>>>>> Token", from my lazy developer standpoint, is a Resource Endpoint an= d >>>>>> Access Token, and the AS is acting as a specialized RS in this case. >>>>>> So my client posts to whatever URL with the 'access token' in the >>>>>> authorization header, just like acting on any other resource I have = a token >>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>> decision point of "Do I have another continue, or do I have a real t= oken >>>>>> for the resource..." But the mechanism is the same to me in the clie= nt. >>>>>> Personally I like that, because if I have an access_token, I already >>>>>> think "Put it in the auth header." >>>>>> >>>>>> So my vote would be +1 for the pull request at this time. >>>>>> -steve >>>>>> >>>>>> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>> wrote: >>>>>> >>>>>>> inline ... >>>>>>> >>>>>>> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>> wrote: >>>>>>> >>>>>>>> Others had already responded to this previous thread, but I wanted >>>>>>>> to add a couple points to clarify some things. >>>>>>>> >>>>>>>> 3) What the client has to do with the "access token" is not the >>>>>>>> same as access tokens for an RS. The client gets a new "access tok= en" for >>>>>>>> each grant request, and for each API call to the AS, and the clien= t learns >>>>>>>> it can not make any more API calls for that specific request when = it does >>>>>>>> not get an "access token" back. This is a completely different des= ign >>>>>>>> pattern than calling an RS API with an access token, and is a new = design >>>>>>>> pattern for calling APIs. This adds complexity to the client that = it would >>>>>>>> not normally have, and I don't think GNAP is the right place to st= art a new >>>>>>>> design pattern. >>>>>>>> >>>>>>>> >>>>>>>> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole >>>>>>>> point of the design is that the client would be doing the same thi= ng with >>>>>>>> the access token at the AS that it does with the RS by re-using th= e access >>>>>>>> token structure. Can you please describe what the differences are,= apart >>>>>>>> from the rotation? Presentation of the token and signing of the me= ssage are >>>>>>>> identical. >>>>>>>> >>>>>>> >>>>>>> The client is getting the "access token" from its API. It is not >>>>>>> using an "access_token" in other API calls to the AS. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Rotation of the access token and artifacts for ongoing continuatio= n >>>>>>>> responses is a separate issue to be discussed: >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>>> >>>>>>>> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have >>>>>>>> new designs =E2=80=94 not that this is one. >>>>>>>> >>>>>>> >>>>>>> You are proposing a new way for an API to provide context for >>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 4) Clients that only want claims from the AS and no access tokens >>>>>>>> will be required to support an API calling mechanism they would no= t have to >>>>>>>> support otherwise. >>>>>>>> >>>>>>>> >>>>>>>> Correct, but the delta between the calls a client would make with >>>>>>>> and without an access token is vanishingly small. The client has t= o sign >>>>>>>> the initial request in some fashion, and it will sign the continua= tion >>>>>>>> request in the same exact fashion, but now include an access token= in that >>>>>>>> request. >>>>>>>> >>>>>>> >>>>>>> Per my other point, there is no value to me in my implementations o= f >>>>>>> passing context back and forth between the client and AS -- so it i= s extra >>>>>>> work providing no value. >>>>>>> >>>>>>> Also, any client authentication mechanism that wants to use the HTT= P >>>>>>> Authentication header is precluded from using it. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Clients making a request to an AS and not getting an access token >>>>>>>> is a new design pattern. I think it has value and should be includ= ed, but >>>>>>>> OAuth today shows us the immense value of getting access tokens fo= r calling >>>>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>>>> >>>>>>>> >>>>>>>> 5) If the AS does not provide an "access token", there is no >>>>>>>> mechanism for a client to delete the request, as the client is not= allowed >>>>>>>> to make a call without an "access token". >>>>>>>> >>>>>>>> >>>>>>>> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, tha= t=E2=80=99s intentional. The AS >>>>>>>> is telling this client instance that it can=E2=80=99t do anything = else with this >>>>>>>> ongoing request. If the AS wants to allow the client to manage it,= it will >>>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D = field. >>>>>>>> >>>>>>> >>>>>>> There is nuance in that intention. A related concern is that >>>>>>> deleting a request does not seem like it is a "continue" operation. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 6) There is no standard identifier for the request. Debugging and >>>>>>>> auditing are hampered by the client and AS having no standard way = to >>>>>>>> identifying a request. While one AS may provide a unique URL for e= ach grant >>>>>>>> request, another AS may use a persistent "access token" to identif= y the >>>>>>>> grant request, and other ASs may issue a new "access token" on eac= h API >>>>>>>> call, providing no persistent identifier for the request. >>>>>>>> >>>>>>>> >>>>>>>> Debugging and auditing this kind of thing are functions of the AS. >>>>>>>> How is interoperability harmed by different ASs having different m= ethods to >>>>>>>> identify their internal data elements? The client doesn=E2=80=99t = need any >>>>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know t= he next steps for >>>>>>>> continuing the negotiation. >>>>>>>> >>>>>>> >>>>>>> Debugging between the client and the AS was what I was referring to= . >>>>>>> How does a client developer identify the request when communicating= to the >>>>>>> AS developer. Seems complicated. >>>>>>> >>>>>>> =E1=90=A7 >>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> =E1=90=A7 >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000750fa705b6711d36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello Dick,

    I'm reading what you=C2=A0write.=C2=A0

    RESTful patterns are well understood, up to a limit. I= 9;ve seen more debate around what's good and what's not that on any= other subject in my entire career. It rarely helps, if ever. Because every= one thinks he applies the concepts correctly anyway.=C2=A0

    I observe we're going too much around XAuth (to ci= te you, "That is all that I used in=C2=A0https://github.com/dickhardt/XAuth-= poc") vs XYZ vs GNAP, in some fashion, while I'm really hoping= we can go forward. I also advise against making personal attacks and would= prefer that we'd keep the discussion to technical arguments only. I= 9;m sure we would all benefit from a win win situation, where we try to arb= itrate the best possible technical solution that=C2=A0matches the group'= ;s goal. Knowing that there are many cases where it's not black and whi= te.=C2=A0

    If you are able to convince me with your= arguments, I'll back your proposal (or any other, for that matter). Bu= t we're really not yet there in that specific case. The cookie comparis= on is far stretched. I don't understand what is complex in having to ha= ndle a token. Please note=C2=A0I'm also expecting some feedback on the = security model that should be put in place around the URI model that you pr= opose.=C2=A0
    =C2=A0
    Then on your last point, I agre= e with you, we can certainly give an example of access token. I'll get = back to you on that.

    Fabien
    ps :=C2=A0I&= #39;m also open to discuss privately=C2=A0with you on a better way to coope= rate in general.=C2=A0

    On Mon, Dec 14, 2020 at 7:00 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    Fabi= en: a discussion would be more productive if you took some time reading wha= t I wrote.

    I am not suggesting pre-registration be manda= tory

    I am not making blame arguments are trying to= start a flamewar -- I am pointing out that a RESTful like pattern is well = understood.

    I am not suggesting we not use cryptog= raphic keys.

    I am saying having an "access to= ken" in addition to a URI adds complexity to both the client and the A= S with little if any value. A URI is all that is needed unless there is a d= esire to make the AS stateless, or pass context between the AS and another = server -- which seems to me of dubious=C2=A0value. That is all that I used = in=C2=A0https://github.com/dickhardt/XAuth-poc=C2=A0

    So far we are discussing the "access token" in abstract terms. W= ould you describe what would be contained in the "access token"?<= /div>

    /Dick



    =



    3D""=E1= =90=A7

    On Fri, Dec 11, 2020 at 5:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    =
    Again speaking in my own name here.=C2=A0

    Dick, we know yo= u'd prefer to have a different design, but this PR shouldn't be abo= ut that.=C2=A0

    Back on y= our 3 items :

    1) yes we = could make pre-register mandatory, but we already decided that wouldn't= be how that would work. We have a client instance that allows a more gener= ic and flexible pattern (which BTW also allows what you want)=C2=A0

    2) instead of blame arguments o= f who's less restful/HATEOAS/whatever that have the tenancy to flame co= nversations, I suggest we speak in less abstract terms and ask ourselves wh= at that means in practice for devs. Stephen and several others (myself incl= uded) have expressed that it wouldn't be harder to implement, it would = even simplify things quite a lot. If you disagree please send us a code sam= ple to really show that point by example, because that's really not obv= ious.=C2=A0

    3) "If = someone has the client credentials, they can impersonate the client, and al= l bets are off." Are you seriously making this argument? Because if yo= u have a better proposal than using cryptographic keys, I'm all hears. = You make it look like there's a problem, while in reality we're onl= y relying on the basic assumption of all modern digital communications.=C2= =A0
    =C2=A0
    And more important= ly you never responded to the issues of how to avoid the security pitfalls = of what you proposed.=C2=A0

    Fabien=C2=A0


    Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Di= ck Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:


    On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <sr= moore@gmail.com> wrote:
    But from the spec:
    "
    When sending a non-continua= tion request to the AS, the RC MUST identify itself by including the=C2=A0<= /span>client=C2=A0field of the request= ...
    ...=
    key (o= bject / string) : The public key of the RC to be used in this request as de= scribed in {{request-key}}. This field is REQUIRED.=C2=A0
    = ...
    "
    So on the initial request, t= he key will be there.=C2=A0
    <= br>
    The client field can be an object or a string. If the client = is pre-registered, then a string could be provided instead of an object.
    =
    =C2=A0

    If you don't have the access token= , then how do you differentiate between two requests from the same web appl= ication by two different users? Is the web application supposed to have dif= ferent credentials for every request?

    The AS returns=C2=A0a URI for manipulating the request. I would chan= ge the spec so that each request would have a unique URI. This is the usual= ly RESTful=C2=A0pattern that the resource (the grant request) has an URI.

    =C2=A0
    So in this case, the easy way out is t= o pass the access token to the client, who then, as i stated before, treats= the continue request as a RS call (albeit=C2=A0a specialized=C2=A0version = of the RS where the RS is the AS) OR to use the unique URL,=C2=A0
    but that seems open to a brute force attack by a malicious RC. (What would= be the point of that attack, I don't know, I guess if someone had the = client credentials but not any subjects/resources they could try to interce= pt the grant via continue... I just don't feel right locking things dow= n to unique URLs that way.)

    If = someone has the client credentials, they can impersonate=C2=A0the client, a= nd all bets are off.

    LOTS of RS servers return a r= esource specific URL -- my proposal is no different.


    =C2=A0
    -steve

    On Fri, Dec 11, 2020 at 5:33 PM Dick= Hardt <dick.hardt@gmail.com> wrote:
    Hi Stephen
    The client is signing the first request. The key *might* be= in the body. The client is signing all the subsequent requests as well. Th= e "access token" is not needed by the client to prove it is autho= rized as the client is proving it is the same client again.

    <= /div>
    In other words, I don't see the need for an access token, so = it does not need to be put in a URL or an auth header.

    =
    If a developer really, really wants to hand context back to the client= for subsequent calls, they can put it in the URL or some other method. Put= ting it in the HTTP Authorization header is confusing because it is NOT an = access token -- it is the context of the request.

    3D""=E1=90=A7

    On Fri, Dec 11, 2020 at 2:01 PM Stephen Moo= re <srmoore@gmail.com> wrote:
    Even though I&= #39;ve only been lightly following things, I feel the need to voice my pref= erence as a developer since I will probably someday have to either write a = RC or RS...=C2=A0

    The way I see it is the RC makes= the initial request to the AS as part of this request, it provides it'= s key in the body... (So no use of the Authorization header)
    At t= his point that request, represented by the continue URL=C2=A0+ "Access= Token", from my lazy developer standpoint, is a Resource Endpoint and= Access Token, and the AS is acting as a specialized RS in this case.
    =
    So my client posts to whatever URL with the 'access token' in = the authorization header, just like acting on any other resource I have a t= oken for. YES, I get a new token value to use every call, and there is a de= cision point of "Do I have another continue, or do I have a real token= for the resource..." But the mechanism is the same to me in the clien= t.
    Personally I like that, because if I have an access_token, I a= lready think "Put it in the auth header."=C2=A0

    So my vote would be=C2=A0+1 for the pull request at this time.
    -steve

    On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    inline ...= =C2=A0

    On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit= .edu> wrote:
    Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.

    3) What the client has to do with the "access token" = is not the same as access tokens for an RS. The client gets a new "acc= ess token" for each grant request, and for each API call to the AS, an= d the client learns it can not make any more API calls for that specific re= quest when it does not get an "access token" back. This is a comp= letely different design pattern than calling an RS API with an access token= ,=C2=A0and is a new design pattern for calling APIs. This adds complexity t= o the client that it would not normally have, and I don't think GNAP is= the right place to start a new design pattern.


    I=E2=80=99m not sure what you mean by these being= different =E2=80=94 the whole point of the design is that the client would= be doing the same thing with the access token at the AS that it does with = the RS by re-using the access token structure. Can you please describe what= the differences are, apart from the rotation? Presentation of the token an= d signing of the message are identical.
    =
    The client is getting the "access token" from its = API. It is not using an "access_token" in other API calls to the = AS.
    =C2=A0

    Rotation of the access token and artifacts f= or ongoing continuation responses is a separate issue to be discussed:=C2= =A0https://github.com/ietf-wg= -gnap/gnap-core-protocol/issues/87

    And for wha= t it=E2=80=99s worth, GNAP is absolutely the right place to have new design= s =E2=80=94 not that this is one.

    You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    =C2=A0

    4) Clients that only want claims from the AS and no access token= s will be required to support an API calling mechanism they would not have = to support otherwise.=C2=A0

    Correct, = but the delta between the calls a client would make with and without an acc= ess token is vanishingly small. The client has to sign the initial request = in some fashion, and it will sign the continuation request in the same exac= t fashion, but now include an access token in that request.=C2=A0

    Per my other point, there is no va= lue to me in my implementations of passing context back and forth between t= he client and AS -- so it is extra work providing no value.

    <= /div>
    Also, any client authentication mechanism=C2=A0that wants to use = the HTTP Authentication header is precluded from using it.

    =C2=A0

    Clients making a request to an AS and not getting= an access token is a new design pattern. I think it has value and should b= e included, but OAuth today shows us the immense value of getting access to= kens for calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern.


    5) If the A= S does not provide an "access token", there is no mechanism for a= client to delete the request, as the client is not allowed to make a call = without an "access token".

    = More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D fiel= d then the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS is telling this client instance that it can= =E2=80=99t do anything else with this ongoing request. If the AS wants to a= llow the client to manage it, it will include the mechanisms to do so in th= e =E2=80=9Ccontinue=E2=80=9D field.

    =
    There is nuance in that intention. A related concern is that del= eting a request does not seem like it is a "continue" operation.<= /div>
    =C2=A0


    6) There is no= standard identifier for the request. Debugging and auditing are hampered b= y the client and AS having no standard way to identifying a request. While = one AS may provide a unique URL for each grant request, another AS may use = a persistent "access token" to identify the grant request, and ot= her ASs may=C2=A0issue a new "access token" on each API call, pro= viding no persistent identifier for the request.
    Debugging and auditing this kind of thing are functions of the AS. H= ow is interoperability harmed by different ASs having different methods to = identify their internal data elements? The client doesn=E2=80=99t need any = knowledge of the AS=E2=80=99s identifiers, it just needs to know the next s= teps for continuing the negotiation.

    Debugging between the client and the AS was what I was referring to. = How does a client developer identify the request when communicating to the = AS developer. Seems complicated.
    =C2=A0
    3D""=E1=90=A7
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    3D""=E1=90=A7
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listi= nfo/txauth
    --000000000000750fa705b6711d36-- From nobody Mon Dec 14 11:38:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7AC3A1884 for ; Mon, 14 Dec 2020 11:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_16=1.048, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHf3-p-I3xRT for ; Mon, 14 Dec 2020 11:38:44 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F963A188C for ; Mon, 14 Dec 2020 11:38:32 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id m12so33190923lfo.7 for ; Mon, 14 Dec 2020 11:38:32 -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=PE/RJrTLmz7dXSIgEfHdt8iAmsHJb6TUrU35Td5Bg6o=; b=LsFXKjHktilEOGjNI+kkVYzknI/p3wFcpvhvSnNZoBnLpOyFQU0QtQET2qKr64iRzc Fe8HH3eZ7lhMozHKowCYRSOyVv5HgwDPuRMDzUq5PxeELw3MYBT4XTY7kRpV33S00AmD h4rADf16vJI9q5D10P5lYPXoM44DNZS/cyxO2V11Xjne+TTIywZD4T9p/CEJGCKlpP9S pdfvGoquULnczVGOWjTcdkVih4/MNND9geahsUaG65SFEjbmZOJJa+bu33BBsPB4pV9y wTYx6uZjCoXtOveE55qfwabcwuaiqY0JXXVayWgkytpLN2lU/sNx/dxrnUM5rZqMczSR vdrQ== 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=PE/RJrTLmz7dXSIgEfHdt8iAmsHJb6TUrU35Td5Bg6o=; b=QqKYYqOmF3ZlKe0RNm758zt7g5RsR8OvhVR81TUG5n4cVOuZGthlp0gsJtkXjLKoas 36SjPZGpgGh29l9JUmhVZuoaTlyMlMFX4qJWE5cC8TO9jb3UhzKfeED2FnWF4VQx1t+L GNxe6LzzLO5ZunxPB4zASEXWxqsmkxxWgJKNQyDtoYVqiIzd40cBGix+HECwMRZ87KW6 bIfmlcLHjjs0qWJH3ZfsyOZ/gKFh6p4ipXHZzEYRspX4Ep9sitA3rAv6HRa+DdPlDg6U soCPgS5esSm64knM00wQv3ZUiEmpsVotVP/Yk7XalPYSIRw1ZzF6X5nRi39pLcShieqf NHfA== X-Gm-Message-State: AOAM532BVtIkupg2PBzDxkuMI5Q+esdSwzBuDuUkEPord49Z7KH86Mgx 2aXk1mh4nIQ1cGL1Ch6g3lkEdwosqAK7Jpt3vBiIXptbro1s3Q== X-Google-Smtp-Source: ABdhPJzYjigUZ5hEYJ1fb8kc94r7jB01J1FVznIV8ajkBhDUXw4A9Kti56hXnPzK/zox5vArk/JwgxrWNDuhq9uHL1M= X-Received: by 2002:a19:4c84:: with SMTP id z126mr9514221lfa.69.1607974710517; Mon, 14 Dec 2020 11:38:30 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 14 Dec 2020 11:37:54 -0800 Message-ID: To: Fabien Imbault Cc: Stephen Moore , txauth gnap , Justin Richer Content-Type: multipart/alternative; boundary="0000000000006da43405b671c972" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 19:38:45 -0000 --0000000000006da43405b671c972 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am proposing a URI that is straight forward, and has no security concerns= . For example, the URI could be: /grant/ eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f The routing code in the AS then is: router.post( '/', grant.create); router.get( '/grant/:grant', grant.read); router.post( '/grant/:grant', grant.update); router.delete( '/grant/:grant', grant.delete); router.options( '/grant/:grant', grant.options); Where there is a "grant" module to manage for working with grant requests. /Dick ps: your previous email, and this one, are making the discussion personal. Happy to discuss privately. =E1=90=A7 --0000000000006da43405b671c972 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    I am proposing a URI that is straight = forward, and has no security=C2=A0concerns.

    For ex= ample, the URI could be:

    <as uri>/grant/<= unique grant id>


    The= routing code in the AS then is:

    ro= uter.post(=C2=A0 =C2=A0 =C2=A0 '/', grant.create);
    router.ge= t(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.read);
    router.post(=C2=A0 =C2=A0 =C2=A0 '/grant= /:grant', grant.update);
    router.delete(=C2=A0 =C2=A0'/grant/:gra= nt', grant.delete);
    router.options( '/grant/:grant', grant.o= ptions);

    Where there is a "grant"= module to manage for working with grant requests.

    /Dick

    ps: your previous email, and this one, are = making the discussion personal. Happy to discuss privately.

    <= /div>
    =3D""=E1=90=A7
    --0000000000006da43405b671c972-- From nobody Mon Dec 14 11:46:14 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BAA3A1903 for ; Mon, 14 Dec 2020 11:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=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=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 bJvp-XzSe1xY for ; Mon, 14 Dec 2020 11:46:10 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4F83A190B for ; Mon, 14 Dec 2020 11:46:09 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id r17so16913015ilo.11 for ; Mon, 14 Dec 2020 11:46:09 -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=Sy73nFTe1Wy/53MD37zvkd/TxuQRVmWQw2AyppTuUK8=; b=Eqe70V/JKmG8u0VVo/HNxCHTtjoGUoY+lhUVpguriNcArfCIMGCW1pRiUbCMwqzlYr d0Tibux3h6A3nRgxCzEvea/YbTVFpFEOhnmyUb8pZwTFh19I7o2epFF11razkpc3uVdu g2DV2x5Uf/oX/wpEa5j90qeyWHmZuVszNIqPsdeIr7UOC12hG6mVDu2iFIpXlHObVR5n indMGLM5GO3wa11xyjBzerSkXq1xgMbhfVw3vhT/+gpTR9UL55rW5PyR4GkYqlUvKWcq HoHVFbUUOhmO4GkksaT+dsLYBbdYVlQlWF12goYGYmRZV/VHQTVw2MfeJpixTk6PDAeT tjZg== 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=Sy73nFTe1Wy/53MD37zvkd/TxuQRVmWQw2AyppTuUK8=; b=MPwTNdfxcnZh5swJqBDGdeZGw73eXBzCSWrrSL4WhqbRPO1SEiIzSnGYznmTACfpuD JH4LHSt3oNjLWXWzsrBoF2/8fDXeyD+a4rjkFidgGE9T4uL0lZmlYP1CHe848E4z3/c3 wC5LrAkBsVwao2tigTlB2r1bOZ6GzEmKMUYYNqp/N8VIgAL6XB1VT23BuvJl7qgbzHSD E33F4CzWwgcv52IQJcRgsPBWpbT/6S/Yaim8ZQuZAIaIsdoWYyNsiwrWrJ1+VXeNMMad CuPogiE5uNDNdvmBWEwE8ccBfhV/W5GdBg5+tP1sJK+XvN4bofSTuHbXN+t6CcnGhkFh D10A== X-Gm-Message-State: AOAM5303m/JY50hYPJU+ARybRTUdTyEFR84wEbuMr/CH1P6W0+iefL/B skIJbvTShU/iEfViZ9avtnRyAs5ESZW+Kp2Q X-Google-Smtp-Source: ABdhPJxonuT+XZB7w9owlD2fZv9AK5hfTWg/Qe5m5fenzR92RdUTSHd71QzoOTZcqKYQss4eRm9ecw== X-Received: by 2002:a92:d03:: with SMTP id 3mr38223055iln.197.1607975168138; Mon, 14 Dec 2020 11:46:08 -0800 (PST) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id e25sm9660932iom.40.2020.12.14.11.46.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 11:46:07 -0800 (PST) Received: by mail-il1-f169.google.com with SMTP id g1so16958862ilk.7 for ; Mon, 14 Dec 2020 11:46:07 -0800 (PST) X-Received: by 2002:a05:6e02:148f:: with SMTP id n15mr8716856ilk.17.1607975166748; Mon, 14 Dec 2020 11:46:06 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Aaron Parecki Date: Mon, 14 Dec 2020 11:45:55 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Dick Hardt Cc: Fabien Imbault , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="0000000000009f2e9b05b671e481" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 19:46:12 -0000 --0000000000009f2e9b05b671e481 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the clear description. However saying "has no security concerns" is a bold claim. Can you clarify how you will ensure that there are no security concerns with this method? My main worry with this is people will start to get "creative" with the values of the things in this URL. We've seen this over and over, everything from using plaintext data in JWT access tokens in OAuth (now the access token contents are visible to clients), to putting data in the OAuth "state" parameter (easy to exploit unless it's signed/encrypted), and I'm sure someone somewhere is putting things in the authorization code that they shouldn't. Aaron On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt wrote: > > I am proposing a URI that is straight forward, and has no > security concerns. > > For example, the URI could be: > > /grant/ > > eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f > > The routing code in the AS then is: > > router.post( '/', grant.create); > router.get( '/grant/:grant', grant.read); > router.post( '/grant/:grant', grant.update); > router.delete( '/grant/:grant', grant.delete); > router.options( '/grant/:grant', grant.options); > > > Where there is a "grant" module to manage for working with grant requests= . > > /Dick > > ps: your previous email, and this one, are making the discussion personal= . > Happy to discuss privately. > > =E1=90=A7 > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000009f2e9b05b671e481 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for the clear description. However saying "has= no security concerns" is a bold claim. Can you clarify how you will e= nsure that there are no security concerns with this method?

    <= div>My main worry with this is people will start to get "creative"= ; with the values of the things in this URL. We've seen this over and o= ver, everything from using plaintext data in JWT access tokens in OAuth (no= w the access token contents are visible to clients), to putting data in the= OAuth "state" parameter (easy to exploit unless it's signed/= encrypted), and I'm sure someone somewhere is putting things in the aut= horization code that they shouldn't.

    Aaron


    On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:
    =
    I am proposing a URI that is straight forward, and has no secur= ity=C2=A0concerns.

    For example, the URI could be:<= /div>

    <as uri>/grant/<unique grant id>
    =


    The routin= g code in the AS then is:

    router.post(=C2=A0 =C2=A0 =C2=A0 '/', grant.crea= te);
    router.get(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', gra= nt.read);
    router.post(=C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.update);
    router.d= elete(=C2=A0 =C2=A0'/grant/:grant', grant.delete);
    router.option= s( '/grant/:grant', grant.options);

    Where there is a "grant" module to manage for working with grant= requests.



    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000009f2e9b05b671e481-- From nobody Mon Dec 14 12:11:23 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56B73A1AB4 for ; Mon, 14 Dec 2020 12:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asjE1DW451Tz for ; Mon, 14 Dec 2020 12:11:20 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB963A1AB0 for ; Mon, 14 Dec 2020 12:11:20 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id y5so18156134iow.5 for ; Mon, 14 Dec 2020 12:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eCLxK2KkDTMIWu705jyzW8amm9npcDvNI/HnR6xRkk0=; b=DrDrs4T1CxzlD6jPidqh1cEhZcbHGAhqwAKOmVfLciyPku5z6ZNTGGDHdj53DfT+uI KMTI042pozuilO6WxsIRaCEFuB/iixTopRlRWVx4bXqybPGXFiWKFt51Dy8JPSMvCk0w qf06tBamYHBCM6+e+O/9IeProcWwp0+DVcm8Q= 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=eCLxK2KkDTMIWu705jyzW8amm9npcDvNI/HnR6xRkk0=; b=f6EO/0xsS3SQs/ai7BKrKLCRlITtdr6aaSIlYWsjccNYzV8xYbc6uGCYjThBccAwAv btJNqC5+p4Sx4vQbJPobx8rWK+4msfFps5oZK4JfJWmJfddsbBmcHcbktGPnnoafVWie wdBwKO6VzEpJBfdNnOBbYyEwdNttQqBJJCkfzd9pDnErm2oHeBhk+LzvjxQ0UIhOQIZh HSdDohVVdAa8pv902T0Uf5cDaR8GDXJRJCfbt2ET+eVAh0+4k5jIAejkscNgHfcI099Y J1dzk2A0kOjTILbWag1KBRbf+Cz/D0vM/z4Jf/iplbTpTZ7jntIcnBjC6YFJebpJ6Qtw 68mA== X-Gm-Message-State: AOAM533BZGz2Lq5XJev22fi3T2b9GvNtSaXipdu9+a9tgxlr2qTeK/SL CT51bKGxSSfaOt5KISDQ4qogP2iMfg57Dj3T0mEa X-Google-Smtp-Source: ABdhPJzKO0TZcyKe6dJ4eusx03fhR45AmS2wXEKjOBzYAVLx47ReRBSKCFLc5BOfYoKnyFmf4zJp0lanYBLovVl35ow= X-Received: by 2002:a5d:84cf:: with SMTP id z15mr30709063ior.81.1607976679131; Mon, 14 Dec 2020 12:11:19 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Warren Parad Date: Mon, 14 Dec 2020 21:11:08 +0100 Message-ID: To: Aaron Parecki Cc: Dick Hardt , Fabien Imbault , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="000000000000c4774405b6723e9d" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 20:11:22 -0000 --000000000000c4774405b6723e9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here's a terrible alternative: It would seem to me that one compromise could be making the object extensible by authorization servers (and their corresponding SDK). In a similar way that JWTs are extensible, we could require explicitly the URI in the spec, and an optional object to be defined by the AS. -------- One source of the problem could be that the language for taking the response object and converting it back into a request one is not well defined. Instead if we allowed an optional headers object to be returned: { uri: "https://as/grant/{grantId}", headers: { 'Authorization': 'Bearer ${accessToken} } } Thereby explicitly telling the client what they need to return back. It avoids the problem of "what to name these things" and also ensures that the data is exactly what the server expects. Additionally it sidesteps the naming issue, where to include tokens, and whether to include them at all. Otherwise it sucks to be in a situation where the benefits/detriments aren't clear to everyone, and potentially we can choose a path forward where both approaches could be used without requiring other clients to jump over arbritrary hurdles suchs as custom implementations. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki wrote: > Thanks for the clear description. However saying "has no security > concerns" is a bold claim. Can you clarify how you will ensure that there > are no security concerns with this method? > > My main worry with this is people will start to get "creative" with the > values of the things in this URL. We've seen this over and over, everythi= ng > from using plaintext data in JWT access tokens in OAuth (now the access > token contents are visible to clients), to putting data in the OAuth > "state" parameter (easy to exploit unless it's signed/encrypted), and I'm > sure someone somewhere is putting things in the authorization code that > they shouldn't. > > Aaron > > > On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt wrote: > >> >> I am proposing a URI that is straight forward, and has no >> security concerns. >> >> For example, the URI could be: >> >> /grant/ >> >> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >> >> The routing code in the AS then is: >> >> router.post( '/', grant.create); >> router.get( '/grant/:grant', grant.read); >> router.post( '/grant/:grant', grant.update); >> router.delete( '/grant/:grant', grant.delete); >> router.options( '/grant/:grant', grant.options); >> >> >> Where there is a "grant" module to manage for working with grant request= s. >> >> /Dick >> >> ps: your previous email, and this one, are making the discussion >> personal. Happy to discuss privately. >> >> =E1=90=A7 >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c4774405b6723e9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Here's a terrible alternative:

    It would seem to me that one compromise could be making the object extens= ible by authorization servers (and their corresponding SDK). In a similar w= ay that JWTs are extensible, we could require explicitly the URI in the spe= c, and an optional object to be defined by the AS.

    -----= ---

    One source of the problem could be that th= e language for taking the response object and converting it back into a req= uest one is not well defined.
    Instead if we allowed an optio= nal headers object to be returned:
    {
    =C2=A0 =C2=A0 uri: "= https://as/grant/{grantId}"= ,
    =C2=A0 =C2=A0 headers: {
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 'Authoriza= tion': 'Bearer ${accessToken}
    =C2=A0 =C2=A0 }
    }
    Thereby explicitly telling the client what they need to return = back. It avoids the problem of "what to name these things" and al= so ensures that the data is exactly what the server expects. Additionally i= t sidesteps the naming issue, where to include tokens, and whether to inclu= de them at all.

    Otherwise it sucks to be in a situ= ation where the benefits/detriments aren't clear to everyone, and poten= tially we can choose a path forward where both approaches could be used wit= hout requiring other clients to jump over arbritrary=C2=A0hurdles suchs as = custom implementations.

    Warren Pa= rad

    Fou= nder, CTO

    Secure your user data and complete your authorization architect= ure. Implement=C2=A0Authress.


    On Mon, Dec 14, 2020 at 8= :46 PM Aaron Parecki <aaron@parecki= .com> wrote:
    Thanks for the clear description. However saying "= ;has no security concerns" is a bold claim. Can you clarify how you wi= ll ensure that there are no security concerns with this method?

    My main worry with this is people will start to get "creative&= quot; with the values of the things in this URL. We've seen this over a= nd over, everything from using plaintext data in JWT access tokens in OAuth= (now the access token contents are visible to clients), to putting data in= the OAuth "state" parameter (easy to exploit unless it's sig= ned/encrypted), and I'm sure someone somewhere is putting things in the= authorization code that they shouldn't.

    Aaron=


    On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    I am proposing a URI that is straight for= ward, and has no security=C2=A0concerns.

    For examp= le, the URI could be:

    <as uri>/grant/<uni= que grant id>

    The routing code in the AS then is:

    router.post(=C2=A0 =C2=A0 =C2=A0 &= #39;/', grant.create);
    router.get(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/= grant/:grant', grant.read);
    router.post(=C2=A0 =C2=A0 =C2=A0 '/grant/:grant', gran= t.update);
    router.delete(=C2=A0 =C2=A0'/grant/:grant', grant.del= ete);
    router.options( '/grant/:grant', grant.options);

    Where there is a "grant" module to manage = for working with grant requests.

    /Dick
    <= br>
    ps: your previous email, and this one, are making the discuss= ion personal. Happy to discuss privately.

    3D""=E1=90=A7
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000c4774405b6723e9d-- From nobody Mon Dec 14 12:25:11 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F043A1B8D for ; Mon, 14 Dec 2020 12:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AUK00JlgvYI for ; Mon, 14 Dec 2020 12:25:06 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40F03A1CB7 for ; Mon, 14 Dec 2020 12:24:32 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id o17so30574771lfg.4 for ; Mon, 14 Dec 2020 12:24:32 -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=4DzTIk11BRyslbpf7hS8WFAqoD9chQIZVXPboKwE/Go=; b=ucI8pCupau8/NdE67GunfmuMllkurz2GEujOVJAJ73P6NI0w/PG5g3UsSR36ams3Da E7xUX7FQE7XxGVLpwv3JdL7u6afuiC2AfAX3RY8ah1UXqxEpdoP3t+QRTCEm/ClveSic bMUyBpfmdjDa9cvyCccPV5fMBrJY/ZotsZpUSKjs6VPjNMtnIljQD/d9HsCvYOnbJ8jP cb+wXjOySTFAflI1RDE6au9/00kJarW4FFhtxUBkLSaQtSagFWw34XZdHZBQOaBxHMS0 XsVcpSVh+vQcMOQvN0DScRS+2fERo0TtvHlN/zd+8hcjNBK1SkqUFdS0YPrcIETEzsy9 N3sg== 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=4DzTIk11BRyslbpf7hS8WFAqoD9chQIZVXPboKwE/Go=; b=g/9UXERz+aOCsFsOBUxmDSTtHhbL+11t+mV5TmEPHGbhYvtKIRKei9sxhJueQAqCYt +5vj4sf5fschY5DwiK/EstdmqgsV8hlek1T3Yc4TGYHLrE1GHBskGmEX/f5wiHFQO982 2tBLO5p3v3wVjeMrS6Y9XeQnKM1S7BZu38B1h8x/jUcXucQ7ERFBAtlBbyXGp0upwzas s92S/4iGK5fQHk+uRwQSP+q/t7f3s+/Jc+156ZWtyVzph2lvSAfkvqskaKA+CbHKh4PL 3GKagXTy5ae1ATRGZB8thUggJkmuw+q3L+FwJD4GL6jLOoFKCBVYFp696x/yTyrV4ziH yglg== X-Gm-Message-State: AOAM532x+7gS6M55Hr9J18CjXY5xiYsaZEDDUAeoMuwEFf8Mtnk3lWZq l/SXDByFvr/QHiu2eMUlWDMOUOdMVGxBDTRyXgY= X-Google-Smtp-Source: ABdhPJyI7cUK7RdBTPTdMY5lv9Tqs+EZC6mzWEMlGlWENj+K1sHP9LImTvKjguC5oi6UJSbNebayT3x4zu3Y7eNImr8= X-Received: by 2002:a19:4c84:: with SMTP id z126mr9573043lfa.69.1607977470568; Mon, 14 Dec 2020 12:24:30 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 14 Dec 2020 12:23:54 -0800 Message-ID: To: Aaron Parecki Cc: Fabien Imbault , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="000000000000f0b21605b6726d03" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 20:25:10 -0000 --000000000000f0b21605b6726d03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't understand what security risks are unique with the GNAP URI relative to other API URIs that have a unique identifier in them. Developers can get "creative" and put "inappropriate" values in any API URI they design. What are the security implications of using a large random value as the ? =E1=90=A7 On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki wrote: > Thanks for the clear description. However saying "has no security > concerns" is a bold claim. Can you clarify how you will ensure that there > are no security concerns with this method? > > My main worry with this is people will start to get "creative" with the > values of the things in this URL. We've seen this over and over, everythi= ng > from using plaintext data in JWT access tokens in OAuth (now the access > token contents are visible to clients), to putting data in the OAuth > "state" parameter (easy to exploit unless it's signed/encrypted), and I'm > sure someone somewhere is putting things in the authorization code that > they shouldn't. > > Aaron > > > On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt wrote: > >> >> I am proposing a URI that is straight forward, and has no >> security concerns. >> >> For example, the URI could be: >> >> /grant/ >> >> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >> >> The routing code in the AS then is: >> >> router.post( '/', grant.create); >> router.get( '/grant/:grant', grant.read); >> router.post( '/grant/:grant', grant.update); >> router.delete( '/grant/:grant', grant.delete); >> router.options( '/grant/:grant', grant.options); >> >> >> Where there is a "grant" module to manage for working with grant request= s. >> >> /Dick >> >> ps: your previous email, and this one, are making the discussion >> personal. Happy to discuss privately. >> >> =E1=90=A7 >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000f0b21605b6726d03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I don't understand what security risks are unique with= the GNAP URI relative to other API URIs that=C2=A0have a unique identifier= =C2=A0in them.=C2=A0

    Developers can get "creati= ve" and put "inappropriate" values in any API URI they desig= n.

    What are the security implications of using a l= arge random value as the <unique grant id>?

    =
    =E1=90=A7

    On Mon, Dec 14, 2020 at 11:46 AM A= aron Parecki <aaron@parecki.com= > wrote:
    Thanks for the clear description. However saying "has no = security concerns" is a bold claim. Can you clarify how you will ensur= e that there are no security concerns with this method?

    = My main worry with this is people will start to get "creative" wi= th the values of the things in this URL. We've seen this over and over,= everything from using plaintext data in JWT access tokens in OAuth (now th= e access token contents are visible to clients), to putting data in the OAu= th "state" parameter (easy to exploit unless it's signed/encr= ypted), and I'm sure someone somewhere is putting things in the authori= zation code that they shouldn't.

    Aaron


    On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wr= ote:

    I am proposing a URI that is straight forward, an= d has no security=C2=A0concerns.

    For example, the = URI could be:

    <as uri>/grant/<unique gran= t id>


    <= div>The routing code in the AS then is:

    router.post(=C2=A0 =C2=A0 =C2=A0 '/= 9;, grant.create);
    router.get(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/grant/:g= rant', grant.read);
    router.post(=C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.update= );
    router.delete(=C2=A0 =C2=A0'/grant/:grant', grant.delete);router.options( '/grant/:grant', grant.options);
    =
    Where there is a "grant" module to manage for work= ing with grant requests.

    /Dick

    ps: your previous email, and this one, are making the discussion pers= onal. Happy to discuss privately.

    3D""=E1=90=A7
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000f0b21605b6726d03-- From nobody Mon Dec 14 12:29:14 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8A3A1BD7 for ; Mon, 14 Dec 2020 12:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjUiXUsMVkjY for ; Mon, 14 Dec 2020 12:29:11 -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 E69FA3A1BD5 for ; Mon, 14 Dec 2020 12:29:10 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BEKT3xs005855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2020 15:29:04 -0500 From: Justin Richer Message-Id: <9CDE8448-B4CD-4DC5-842D-3C58C5A322ED@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_90954ED7-9635-4D20-A232-31A14968CD1F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 14 Dec 2020 15:29:03 -0500 In-Reply-To: Cc: Aaron Parecki , Dick Hardt , Fabien Imbault , txauth gnap , Steve Moore To: Warren Parad References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 20:29:13 -0000 --Apple-Mail=_90954ED7-9635-4D20-A232-31A14968CD1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Warren, (as editor): Your proposal below is not dissimilar to what=E2=80=99s in the current = spec text: the URI is required, and the access token is optional. If the = access token is included, the client has to include it in its request. = The feedback from the working group during the IETF109 meeting, and = leading up to it, was nearly universally that this optionality was not = helpful, especially to client developers. The editors=E2=80=99 PR being = discussed here removes that optionality by making both fields required = with only one method of presentation, and therefore a single code path = for the client. =E2=80=94 Justin > On Dec 14, 2020, at 3:11 PM, Warren Parad wrote: >=20 > Here's a terrible alternative: >=20 > It would seem to me that one compromise could be making the object = extensible by authorization servers (and their corresponding SDK). In a = similar way that JWTs are extensible, we could require explicitly the = URI in the spec, and an optional object to be defined by the AS. >=20 > -------- >=20 > One source of the problem could be that the language for taking the = response object and converting it back into a request one is not well = defined. > Instead if we allowed an optional headers object to be returned: > { > uri: "https://as/grant/{grantId} = ", > headers: { > 'Authorization': 'Bearer ${accessToken} > } > } >=20 > Thereby explicitly telling the client what they need to return back. = It avoids the problem of "what to name these things" and also ensures = that the data is exactly what the server expects. Additionally it = sidesteps the naming issue, where to include tokens, and whether to = include them at all. >=20 > Otherwise it sucks to be in a situation where the benefits/detriments = aren't clear to everyone, and potentially we can choose a path forward = where both approaches could be used without requiring other clients to = jump over arbritrary hurdles suchs as custom implementations. >=20 >=20 > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . >=20 >=20 > On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki > wrote: > Thanks for the clear description. However saying "has no security = concerns" is a bold claim. Can you clarify how you will ensure that = there are no security concerns with this method? >=20 > My main worry with this is people will start to get "creative" with = the values of the things in this URL. We've seen this over and over, = everything from using plaintext data in JWT access tokens in OAuth (now = the access token contents are visible to clients), to putting data in = the OAuth "state" parameter (easy to exploit unless it's = signed/encrypted), and I'm sure someone somewhere is putting things in = the authorization code that they shouldn't. >=20 > Aaron >=20 >=20 > On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt > wrote: >=20 > I am proposing a URI that is straight forward, and has no security = concerns. >=20 > For example, the URI could be: >=20 > /grant/ >=20 > eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f = >=20 > The routing code in the AS then is: >=20 > router.post ( '/', grant.create); > router.get( '/grant/:grant', grant.read); > router.post ( '/grant/:grant', = grant.update); > router.delete( '/grant/:grant', grant.delete); > router.options( '/grant/:grant', grant.options); >=20 > Where there is a "grant" module to manage for working with grant = requests. >=20 > /Dick >=20 > ps: your previous email, and this one, are making the discussion = personal. Happy to discuss privately. >=20 > =E1=90=A7 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_90954ED7-9635-4D20-A232-31A14968CD1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Warren,

    (as= editor):

    Your = proposal below is not dissimilar to what=E2=80=99s in the current spec = text: the URI is required, and the access token is optional. If the = access token is included, the client has to include it in its request. = The feedback from the working group during the IETF109 meeting, and = leading up to it, was nearly universally that this optionality was not = helpful, especially to client developers. The editors=E2=80=99 PR being = discussed here removes that optionality by making both fields required = with only one method of presentation, and therefore a single code path = for the client.

     =E2=80=94 Justin

    On Dec = 14, 2020, at 3:11 PM, Warren Parad <wparad@rhosys.ch> wrote:

    Here's a terrible alternative:

    It would seem to me that one compromise could be making = the object extensible by authorization servers (and their corresponding = SDK). In a similar way that JWTs are extensible, we could require = explicitly the URI in the spec, and an optional object to be defined by = the AS.

    --------

    One = source of the problem could be that the language for taking the response = object and converting it back into a request one is not well = defined.
    Instead if we allowed an = optional headers object to be returned:
    {
        uri: "https://as/grant/{grantId}",
        = headers: {
            'Authorization': = 'Bearer ${accessToken}
        }
    }

    Thereby explicitly telling the client what they need to = return back. It avoids the problem of "what to name these things" and = also ensures that the data is exactly what the server expects. = Additionally it sidesteps the naming issue, where to include tokens, and = whether to include them at all.

    Otherwise it sucks to be in a situation = where the benefits/detriments aren't clear to everyone, and potentially = we can choose a path forward where both approaches could be used without = requiring other clients to jump over arbritrary hurdles suchs as = custom implementations.

    Warren Parad
    Founder, = CTO
    Secure your user data and complete your = authorization architecture. Implement Authress.


    On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki = <aaron@parecki.com> wrote:
    Thanks for the clear description. However saying = "has no security concerns" is a bold claim. Can you clarify how you will = ensure that there are no security concerns with this method?

    My main worry with this = is people will start to get "creative" with the values of the things in = this URL. We've seen this over and over, everything from using plaintext = data in JWT access tokens in OAuth (now the access token contents are = visible to clients), to putting data in the OAuth "state" parameter = (easy to exploit unless it's signed/encrypted), and I'm sure someone = somewhere is putting things in the authorization code that they = shouldn't.

    Aaron


    On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    I am proposing a URI that is straight forward, and has no = security concerns.

    For example, the URI could be:

    <as uri>/grant/<unique grant = id>

    eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b8= 9f

    The = routing code in the AS then is:

    router.post(      '/', = grant.create);
    router.get(        = '/grant/:grant', grant.read);
    router.post(      '/grant/:grant', = grant.update);
    router.delete(   '/grant/:grant', = grant.delete);
    router.options( '/grant/:grant', = grant.options);

    Where there is a "grant" module to manage for working with = grant requests.

    /Dick

    ps: your previous email, and this one, are making the = discussion personal. Happy to discuss privately.

    3D""=E1=90=A7
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    -- 
    TXAuth = mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth

    = --Apple-Mail=_90954ED7-9635-4D20-A232-31A14968CD1F-- From nobody Mon Dec 14 12:41:55 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53653A1CB3 for ; Mon, 14 Dec 2020 12:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrkTGVC5krf7 for ; Mon, 14 Dec 2020 12:41:51 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001CF3A1C8B for ; Mon, 14 Dec 2020 12:41:50 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id q1so17124218ilt.6 for ; Mon, 14 Dec 2020 12:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cpTWy7YcPIyxOTts/tByF+j9sQvW8Gp8mmUExhLf3Kc=; b=Xj1X105Kf29S8CU2j9kEmvZ+ZCR05Qo+p/FfDWj1zs4pWQN7F3vYRy4y41NIsyfnVB QBNjsKMhRJsfE8Q54U7KwDbWHarb+pwBT9Cmq9zvhotp5yVWKIx/lbIeB2VJdPotVTrS 9UZItOTkiSwnys2OK5OJrN4P/pD/gTTgqdt3A= 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=cpTWy7YcPIyxOTts/tByF+j9sQvW8Gp8mmUExhLf3Kc=; b=XuvUv3hTOPYfH/sJPjnkXhOAnJYNcoJd+dHq+6/JEtiYakvViUbjkHvqwN7STm4eqF iUMCagniGbWglehGdSMgz0aidxPCzxK+nKCNbVqzY3ngSCZdnnsdaWateDYxW/D1iuW9 XsG3xGSe9Pj9J2OyRGHNHFStP/SgsfM/9sXnw5lVJfQtTrYYKkE8tJ9GkGPo/2bqt3xT gFb2ynOyJZ1aYvlyGB6UPyGl+orp9oSgrjxxx6jK0/goinagNI1X9DGngFrvUV591Z12 uyM/WF+ewUMtMGzYwjBrrgyF3GfBs08Abq++RrxyeD3G9xQCEvVwR+hxmSp8ooXtLGm5 4uaw== X-Gm-Message-State: AOAM530yq0S3spl/pHyDZ3+50TPrit8C5eJFRjOA1QiJyLPSnsB86Q7J LaSUl4YN+myi93ZKhz9SHTrPprwjQPBLT17grpI1 X-Google-Smtp-Source: ABdhPJzK2cbB26jmf/Xp4OGjC+dc9g74LXMeOSXSdx7dig8+pEGxMo97wt1lCRN8ARKtp+3hQ309M29LEa92gz6osCo= X-Received: by 2002:a05:6e02:154c:: with SMTP id j12mr28017484ilu.33.1607978510031; Mon, 14 Dec 2020 12:41:50 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> <9CDE8448-B4CD-4DC5-842D-3C58C5A322ED@mit.edu> In-Reply-To: <9CDE8448-B4CD-4DC5-842D-3C58C5A322ED@mit.edu> From: Warren Parad Date: Mon, 14 Dec 2020 21:41:38 +0100 Message-ID: To: Justin Richer Cc: Aaron Parecki , Dick Hardt , Fabien Imbault , txauth gnap , Steve Moore Content-Type: multipart/alternative; boundary="000000000000e5b84a05b672abeb" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 20:41:54 -0000 --000000000000e5b84a05b672abeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So then I would say the question becomes, why force AS to create "access tokens" (or whatever we want to call them) if they don't see the benefit of doing so. I.e. right now the Warren AS (and the Dick AS) both think we would not be generating "access tokens". If the spec requires it, I would probably just hard code the same value in every request because my AS doesn't see the value in requiring it when I'm in control of the URI. If I understand the discussion correctly, we are trying to prevent AS from exposing the uri containing the "access token", because doing so would hypothetically create an attack surface for the AS. If that's the case, then I would say, forcing the token to be in auth header only provides a negligible amount of surface decrease and thus the extra complexity is not well offset by the security improvement. So for me rather than arguing if there is any benefit at all, I'll make a stronger argument: *If there is a benefit to using the access token, it surely can't be a meaningful amount in such a way that it's important from the GNAP protocol standpoint to provide this mechanism for improvement.* Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Mon, Dec 14, 2020 at 9:29 PM Justin Richer wrote: > Warren, > > (as editor): > > Your proposal below is not dissimilar to what=E2=80=99s in the current sp= ec text: > the URI is required, and the access token is optional. If the access toke= n > is included, the client has to include it in its request. The feedback fr= om > the working group during the IETF109 meeting, and leading up to it, was > nearly universally that this optionality was not helpful, especially to > client developers. The editors=E2=80=99 PR being discussed here removes t= hat > optionality by making both fields required with only one method of > presentation, and therefore a single code path for the client. > > =E2=80=94 Justin > > On Dec 14, 2020, at 3:11 PM, Warren Parad wrote: > > Here's a terrible alternative: > > It would seem to me that one compromise could be making the object > extensible by authorization servers (and their corresponding SDK). In a > similar way that JWTs are extensible, we could require explicitly the URI > in the spec, and an optional object to be defined by the AS. > > -------- > > One source of the problem could be that the language for taking the > response object and converting it back into a request one is not well > defined. > Instead if we allowed an optional headers object to be returned: > { > uri: "https://as/grant/{grantId}", > headers: { > 'Authorization': 'Bearer ${accessToken} > } > } > > Thereby explicitly telling the client what they need to return back. It > avoids the problem of "what to name these things" and also ensures that t= he > data is exactly what the server expects. Additionally it sidesteps the > naming issue, where to include tokens, and whether to include them at all= . > > Otherwise it sucks to be in a situation where the benefits/detriments > aren't clear to everyone, and potentially we can choose a path forward > where both approaches could be used without requiring other clients to ju= mp > over arbritrary hurdles suchs as custom implementations. > > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki wrote: > >> Thanks for the clear description. However saying "has no security >> concerns" is a bold claim. Can you clarify how you will ensure that ther= e >> are no security concerns with this method? >> >> My main worry with this is people will start to get "creative" with the >> values of the things in this URL. We've seen this over and over, everyth= ing >> from using plaintext data in JWT access tokens in OAuth (now the access >> token contents are visible to clients), to putting data in the OAuth >> "state" parameter (easy to exploit unless it's signed/encrypted), and I'= m >> sure someone somewhere is putting things in the authorization code that >> they shouldn't. >> >> Aaron >> >> >> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt wrote= : >> >>> >>> I am proposing a URI that is straight forward, and has no >>> security concerns. >>> >>> For example, the URI could be: >>> >>> /grant/ >>> >>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >>> >>> The routing code in the AS then is: >>> >>> router.post( '/', grant.create); >>> router.get( '/grant/:grant', grant.read); >>> router.post( '/grant/:grant', grant.update); >>> router.delete( '/grant/:grant', grant.delete); >>> router.options( '/grant/:grant', grant.options); >>> >>> >>> Where there is a "grant" module to manage for working with grant >>> requests. >>> >>> /Dick >>> >>> ps: your previous email, and this one, are making the discussion >>> personal. Happy to discuss privately. >>> >>> =E1=90=A7 >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000e5b84a05b672abeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    So then I would say the question becomes, why force AS to = create "access tokens" (or whatever we want to call them) if they= don't see the benefit of doing so. I.e. right now the Warren AS (and t= he Dick AS) both think we would not be generating "access tokens"= . If the spec requires it, I would probably just hard code the same value i= n every request because my AS doesn't see the value in requiring it whe= n I'm in control of the URI.

    If I understand the dis= cussion correctly, we are trying to prevent AS from exposing the uri contai= ning the "access token", because doing so would hypothetically cr= eate an attack surface=C2=A0for the AS. If that's the case, then I woul= d say, forcing the token to be in auth header only provides a negligible am= ount of surface decrease and thus the extra complexity is not well offset b= y the security improvement. So for me rather than arguing if there is any b= enefit at all, I'll make a stronger argument:
    If there is = a benefit to using the access token, it surely can't be a meaningful am= ount in such a way that it's important from the GNAP protocol standpoin= t to provide this mechanism for improvement.

    <= div>
    <= tr style=3D"height:0pt"><= /table>Secure your user data and complete= your authorization architecture. Implement=C2=A0Authress<= span style=3D"font-size:x-small">.


    On Mon, Dec 14, 2020 at 9:29 PM Justin Richer <jricher@mit.edu> wrote:
    Warr= en,

    (as editor):

    Your proposal = below is not dissimilar to what=E2=80=99s in the current spec text: the URI= is required, and the access token is optional. If the access token is incl= uded, the client has to include it in its request. The feedback from the wo= rking group during the IETF109 meeting, and leading up to it, was nearly un= iversally that this optionality was not helpful, especially to client devel= opers. The editors=E2=80=99 PR being discussed here removes that optionalit= y by making both fields required with only one method of presentation, and = therefore a single code path for the client.

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

    On De= c 14, 2020, at 3:11 PM, Warren Parad <wparad@rhosys.ch> wrote:

    Here's a terrible alternative:
    =
    It would seem to me that one compromise could be making the objec= t extensible by authorization servers (and their corresponding SDK). In a s= imilar way that JWTs are extensible, we could require explicitly the URI in= the spec, and an optional object to be defined by the AS.

    --------

    One source of the problem could be= that the language for taking the response object and converting it back in= to a request one is not well defined.
    Instead if we allowed = an optional headers object to be returned:
    {
    =C2=A0 =C2=A0 uri= : "https:= //as/grant/{grantId}",
    =C2=A0 =C2=A0 headers: {
    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 'Authorization': 'Bearer ${accessToken}
    = =C2=A0 =C2=A0 }
    }

    Thereby explicitly telling th= e client what they need to return back. It avoids the problem of "what= to name these things" and also ensures that the data is exactly what = the server expects. Additionally it sidesteps the naming issue, where to in= clude tokens, and whether to include them at all.

    = Otherwise it sucks to be in a situation where the benefits/detriments aren&= #39;t clear to everyone, and potentially we can choose a path forward where= both approaches could be used without requiring other clients to jump over= arbritrary=C2=A0hurdles suchs as custom implementations.

    Warren Parad

    Founder, CTO

    Warren Parad
    <= div style=3D"line-height:1.2;border-left:1pt solid rgb(255,255,255);border-= right:1pt solid rgb(255,255,255);border-bottom:1pt solid rgb(255,255,255);m= argin-top:0pt;margin-bottom:0pt">Founder, CTO
    Secure your= user data and complete your authorization architecture. Implement=C2=A0Authress.


    On Mon, Dec 14= , 2020 at 8:46 PM Aaron Parecki <aaron@parecki.com> wrote:
    Thanks for the clear desc= ription. However saying "has no security concerns" is a bold clai= m. Can you clarify how you will ensure that there are no security concerns = with this method?

    My main worry with this is people will= start to get "creative" with the values of the things in this UR= L. We've seen this over and over, everything from using plaintext data = in JWT access tokens in OAuth (now the access token contents are visible to= clients), to putting data in the OAuth "state" parameter (easy t= o exploit unless it's signed/encrypted), and I'm sure someone somew= here is putting things in the authorization code that they shouldn't.

    Aaron


    On Mon, Dec 14, 2020 at 1= 1:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    I am proposi= ng a URI that is straight forward, and has no security=C2=A0concerns.
    =

    For example, the URI could be:

    <as uri>/grant/<unique grant id>


    The routing code= in the AS then is:

    router.post(=C2=A0 =C2=A0 =C2=A0 '/', grant.create)= ;
    router.get(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.= read);
    router.post= (=C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.update);
    router.del= ete(=C2=A0 =C2=A0'/grant/:grant', grant.delete);
    router.options(= '/grant/:grant', grant.options);

    W= here there is a "grant" module to manage for working with grant r= equests.

    /Dick

    ps: your p= revious email, and this one, are making the discussion personal. Happy to d= iscuss privately.

    --= =C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.iet= f.org/mailman/listinfo/txauth
    --000000000000e5b84a05b672abeb-- From nobody Mon Dec 14 13:03:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D863A1009 for ; Mon, 14 Dec 2020 13:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.345 X-Spam-Level: * X-Spam-Status: No, score=1.345 tagged_above=-999 required=5 tests=[FONT_INVIS_MSGID=1.329, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Who8IgyDxVYn for ; Mon, 14 Dec 2020 13:03:32 -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 06EAB3A1003 for ; Mon, 14 Dec 2020 13:03:31 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BEL3SLM020455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2020 16:03:29 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4F44FA63-819F-44B3-BE6F-791B05BFBA03" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 14 Dec 2020 16:03:28 -0500 In-Reply-To: Cc: Aaron Parecki , Dick Hardt , Fabien Imbault , txauth gnap , Steve Moore To: Warren Parad References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> <9CDE8448-B4CD-4DC5-842D-3C58C5A322ED@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 21:03:34 -0000 --Apple-Mail=_4F44FA63-819F-44B3-BE6F-791B05BFBA03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (As an individual): There are a number of reasons and use cases that drive toward using an = access token. A stateless, distributed AS is one of them, and an access = token gives us a proven better way to shield the components from each = other. While we could tell people to put that information into the URI, = we=E2=80=99d then need to tell people how to protect all the information = in the URI. This is a case where we can avoid problems in the design = instead of having to fix them later.=20 Then there=E2=80=99s the question of client authentication: After the = initial request, the AS doesn=E2=80=99t even need the client to = =E2=80=9Cauthenticate=E2=80=9D as much as it needs to make sure that the = same party is making the future call. Authentication only applies to = clients that have a pre-registered key at the AS, and in that case only = in the initial call. Anything after that can be tied to the context of = the ongoing request, in much the same way an any other protected API = just needs to know the context of the token. Now, from a client=E2=80=99s = perspective, it=E2=80=99s still signing the continue request exactly = like it did the initial request, it=E2=80=99s just including the access = token as a header and covering it with the signature. And the AS can = still look up the client=E2=80=99s instance information based on that = request, just like any RS with access to that information would be able = to. But at this point, the AS doesn=E2=80=99t :have: to do that because = it can associate any rights and features for that request in the first = step and carry that forward. After that first stage, it=E2=80=99s just = modification of the ongoing request, and as long as that modification is = being made by the authorized party (the client with access to the key) = then it works. It=E2=80=99s the same argument that OAuth made for moving = APIs to access tokens and away from API keys, and now that we are = viewing =E2=80=9Ccontinue=E2=80=9D as an API for the client to call, = with multiple actions over time, then it makes sense to treat it like = other APIs. So, what does this mean for an AS to create access tokens for this step? = Well, for the vast majority of AS=E2=80=99s out there, creating an = access token is something they=E2=80=99re already really good at, and = need to be prepared to do anyway. For an AS that isn=E2=80=99t dealing = in access tokens at all, it=E2=80=99s an extra field to include, you are = right.But even then, it would be trivial for an AS to create, for = example, a simple signed JWT for continuation access to hand to the = client. Do you want that token to last for 10 years and be good across = all continuation requests for a given client? Go for it, that=E2=80=99s = your security decision to make. And you can still use unique identifiers = in your URLs, which has always been the case. But importantly, this = specific use case can be supported without getting in the way of other = patterns and at minimal cost. The cost to other patterns in terms of = complexity and security risk is far greater if we use only URLs. =E2=80=94 Justin > On Dec 14, 2020, at 3:41 PM, Warren Parad wrote: >=20 > So then I would say the question becomes, why force AS to create = "access tokens" (or whatever we want to call them) if they don't see the = benefit of doing so. I.e. right now the Warren AS (and the Dick AS) both = think we would not be generating "access tokens". If the spec requires = it, I would probably just hard code the same value in every request = because my AS doesn't see the value in requiring it when I'm in control = of the URI. >=20 > If I understand the discussion correctly, we are trying to prevent AS = from exposing the uri containing the "access token", because doing so = would hypothetically create an attack surface for the AS. If that's the = case, then I would say, forcing the token to be in auth header only = provides a negligible amount of surface decrease and thus the extra = complexity is not well offset by the security improvement. So for me = rather than arguing if there is any benefit at all, I'll make a stronger = argument: > If there is a benefit to using the access token, it surely can't be a = meaningful amount in such a way that it's important from the GNAP = protocol standpoint to provide this mechanism for improvement. >=20 >=20 > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . >=20 >=20 > On Mon, Dec 14, 2020 at 9:29 PM Justin Richer > wrote: > Warren, >=20 > (as editor): >=20 > Your proposal below is not dissimilar to what=E2=80=99s in the current = spec text: the URI is required, and the access token is optional. If the = access token is included, the client has to include it in its request. = The feedback from the working group during the IETF109 meeting, and = leading up to it, was nearly universally that this optionality was not = helpful, especially to client developers. The editors=E2=80=99 PR being = discussed here removes that optionality by making both fields required = with only one method of presentation, and therefore a single code path = for the client. >=20 > =E2=80=94 Justin >=20 >> On Dec 14, 2020, at 3:11 PM, Warren Parad > wrote: >>=20 >> Here's a terrible alternative: >>=20 >> It would seem to me that one compromise could be making the object = extensible by authorization servers (and their corresponding SDK). In a = similar way that JWTs are extensible, we could require explicitly the = URI in the spec, and an optional object to be defined by the AS. >>=20 >> -------- >>=20 >> One source of the problem could be that the language for taking the = response object and converting it back into a request one is not well = defined. >> Instead if we allowed an optional headers object to be returned: >> { >> uri: "https://as/grant/{grantId} = ", >> headers: { >> 'Authorization': 'Bearer ${accessToken} >> } >> } >>=20 >> Thereby explicitly telling the client what they need to return back. = It avoids the problem of "what to name these things" and also ensures = that the data is exactly what the server expects. Additionally it = sidesteps the naming issue, where to include tokens, and whether to = include them at all. >>=20 >> Otherwise it sucks to be in a situation where the benefits/detriments = aren't clear to everyone, and potentially we can choose a path forward = where both approaches could be used without requiring other clients to = jump over arbritrary hurdles suchs as custom implementations. >>=20 >>=20 >> Warren Parad >> Founder, CTO >> Secure your user data and complete your authorization architecture. = Implement Authress . >>=20 >>=20 >> On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki > wrote: >> Thanks for the clear description. However saying "has no security = concerns" is a bold claim. Can you clarify how you will ensure that = there are no security concerns with this method? >>=20 >> My main worry with this is people will start to get "creative" with = the values of the things in this URL. We've seen this over and over, = everything from using plaintext data in JWT access tokens in OAuth (now = the access token contents are visible to clients), to putting data in = the OAuth "state" parameter (easy to exploit unless it's = signed/encrypted), and I'm sure someone somewhere is putting things in = the authorization code that they shouldn't. >>=20 >> Aaron >>=20 >>=20 >> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt > wrote: >>=20 >> I am proposing a URI that is straight forward, and has no security = concerns. >>=20 >> For example, the URI could be: >>=20 >> /grant/ >>=20 >> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f = >>=20 >> The routing code in the AS then is: >>=20 >> router.post ( '/', grant.create); >> router.get( '/grant/:grant', grant.read); >> router.post ( '/grant/:grant', = grant.update); >> router.delete( '/grant/:grant', grant.delete); >> router.options( '/grant/:grant', grant.options); >>=20 >> Where there is a "grant" module to manage for working with grant = requests. >>=20 >> /Dick >>=20 >> ps: your previous email, and this one, are making the discussion = personal. Happy to discuss privately. >>=20 >> =E1=90=A7 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_4F44FA63-819F-44B3-BE6F-791B05BFBA03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (As = an individual):

    There = are a number of reasons and use cases that drive toward using an access = token. A stateless, distributed AS is one of them, and an access token = gives us a proven better way to shield the components from each other. = While we could tell people to put that information into the URI, we=E2=80=99= d then need to tell people how to protect all the information in the = URI. This is a case where we can avoid problems in the design instead of = having to fix them later. 

    Then there=E2=80=99s the question of = client authentication:  After the initial request, the AS doesn=E2=80= =99t even need the client to =E2=80=9Cauthenticate=E2=80=9D as much as = it needs to make sure that the same party is making the future call. = Authentication only applies to clients that have a pre-registered key at = the AS, and in that case only in the initial call. Anything after that = can be tied to the context of the ongoing request, in much the same way = an any other protected API just needs to know the context of the token. = Now, from a client=E2=80=99s perspective, it=E2=80=99s still signing the = continue request exactly like it did the initial request, it=E2=80=99s = just including the access token as a header and covering it with the = signature. And the AS can still look up the client=E2=80=99s instance = information based on that request, just like any RS with access to that = information would be able to. But at this point, the AS doesn=E2=80=99t = :have: to do that because it can associate any rights and features for = that request in the first step and carry that forward. After that first = stage, it=E2=80=99s just modification of the ongoing request, and as = long as that modification is being made by the authorized party (the = client with access to the key) then it works. It=E2=80=99s the same = argument that OAuth made for moving APIs to access tokens and away from = API keys, and now that we are viewing =E2=80=9Ccontinue=E2=80=9D as an = API for the client to call, with multiple actions over time, then it = makes sense to treat it like other APIs.

    So, what does this mean for an AS to = create access tokens for this step? Well, for the vast majority of = AS=E2=80=99s out there, creating an access token is something they=E2=80=99= re already really good at, and need to be prepared to do anyway. For an = AS that isn=E2=80=99t dealing in access tokens at all, it=E2=80=99s an = extra field to include, you are right.But even then, it would be trivial = for an AS to create, for example, a simple signed JWT for continuation = access to hand to the client. Do you want that token to last for 10 = years and be good across all continuation requests for a given client? = Go for it, that=E2=80=99s your security decision to make. And you can = still use unique identifiers in your URLs, which has always been the = case. But importantly, this specific use case can be supported without = getting in the way of other patterns and at minimal cost. The cost to = other patterns in terms of complexity and security risk is far greater = if we use only URLs.

     =E2=80=94 Justin

    On Dec = 14, 2020, at 3:41 PM, Warren Parad <wparad@rhosys.ch> wrote:

    So then I would say the question = becomes, why force AS to create "access tokens" (or whatever we want to = call them) if they don't see the benefit of doing so. I.e. right now the = Warren AS (and the Dick AS) both think we would not be generating = "access tokens". If the spec requires it, I would probably just hard = code the same value in every request because my AS doesn't see the value = in requiring it when I'm in control of the URI.

    If I understand the discussion = correctly, we are trying to prevent AS from exposing the uri containing = the "access token", because doing so would hypothetically create an = attack surface for the AS. If that's the case, then I would say, = forcing the token to be in auth header only provides a negligible amount = of surface decrease and thus the extra complexity is not well offset by = the security improvement. So for me rather than arguing if there is any = benefit at all, I'll make a stronger argument:
    If there is a benefit to using the access token, it surely = can't be a meaningful amount in such a way that it's important from the = GNAP protocol standpoint to provide this mechanism for = improvement.

    Warren Parad
    Founder, = CTO
    Secure your user data and = complete your authorization architecture. Implement Authress.


    On Mon, Dec = 14, 2020 at 9:29 PM Justin Richer <jricher@mit.edu> wrote:
    Warren,

    (as editor):

    Your proposal below is not dissimilar to what=E2=80=99s in = the current spec text: the URI is required, and the access token is = optional. If the access token is included, the client has to include it = in its request. The feedback from the working group during the IETF109 = meeting, and leading up to it, was nearly universally that this = optionality was not helpful, especially to client developers. The = editors=E2=80=99 PR being discussed here removes that optionality by = making both fields required with only one method of presentation, and = therefore a single code path for the client.

     =E2=80=94 Justin

    On Dec 14, 2020, at 3:11 PM, Warren Parad = <wparad@rhosys.ch> wrote:

    Here's a terrible = alternative:

    It would seem to = me that one compromise could be making the object extensible by = authorization servers (and their corresponding SDK). In a similar way = that JWTs are extensible, we could require explicitly the URI in the = spec, and an optional object to be defined by the AS.

    --------

    One source of the = problem could be that the language for taking the response object and = converting it back into a request one is not well defined.
    Instead if we allowed an optional headers = object to be returned:
    {
      =   uri: "https://as/grant/{grantId}",
        = headers: {
            'Authorization': = 'Bearer ${accessToken}
        }
    }

    Thereby explicitly telling the client what they need to = return back. It avoids the problem of "what to name these things" and = also ensures that the data is exactly what the server expects. = Additionally it sidesteps the naming issue, where to include tokens, and = whether to include them at all.

    Otherwise it sucks to be in a situation = where the benefits/detriments aren't clear to everyone, and potentially = we can choose a path forward where both approaches could be used without = requiring other clients to jump over arbritrary hurdles suchs as = custom implementations.

    Warren Parad
    Founder, = CTO
    Secure your user data and = complete your authorization architecture. Implement Authress.


    On Mon, Dec 14, = 2020 at 8:46 PM Aaron Parecki <aaron@parecki.com> wrote:
    Thanks = for the clear description. However saying "has no security concerns" is = a bold claim. Can you clarify how you will ensure that there are no = security concerns with this method?

    My main worry with this is people will = start to get "creative" with the values of the things in this URL. We've = seen this over and over, everything from using plaintext data in JWT = access tokens in OAuth (now the access token contents are visible to = clients), to putting data in the OAuth "state" parameter (easy to = exploit unless it's signed/encrypted), and I'm sure someone somewhere is = putting things in the authorization code that they shouldn't.

    Aaron


    On Mon, Dec = 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    I am proposing a URI = that is straight forward, and has no security concerns.

    For example, the URI = could be:

    <as= uri>/grant/<unique grant id>

    eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b8= 9f

    The = routing code in the AS then is:

    router.post(      '/', = grant.create);
    router.get(        = '/grant/:grant', grant.read);
    router.post(      '/grant/:grant', = grant.update);
    router.delete(   '/grant/:grant', = grant.delete);
    router.options( '/grant/:grant', = grant.options);

    Where there is a "grant" module to manage for working with = grant requests.

    /Dick

    ps: your previous email, and this one, are making the = discussion personal. Happy to discuss privately.

    3D""=E1=90=A7
    -- 
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    -- 
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth


    = --Apple-Mail=_4F44FA63-819F-44B3-BE6F-791B05BFBA03-- From nobody Mon Dec 14 13:19:37 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9E03A12A2 for ; Mon, 14 Dec 2020 13:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjVydv6J1lXI for ; Mon, 14 Dec 2020 13:19:33 -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 7B6C33A129A for ; Mon, 14 Dec 2020 13:19:33 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id z5so18341467iob.11 for ; Mon, 14 Dec 2020 13:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mymMN65KdMgVl3wAqg5NiaBMtjIpu5H8U2foaZl7zbw=; b=oTi+CEu2MVk/P4LnSf99FU3h9wVBm6dveKJLyjNtcjFP2FphXJwTw+ij79WUI/J1Qy tXjbFXW9oprHuNrui/WO2wjudqUWSyNWeyhK2YYBY0eXqXlbyZ3He4V7kS/6evxkoqik gVyI2e9IYD3xa2JVBejhFxIhY3bP5bSHjCno+o58TWTLpYvTZzcSNDKY12VNEmC5/gOz IsDeLmmAGbXhYQBhD0F0gDjV1SGyZp7OawxIw7kWC+5TAhsIyWmnxO5p1fuzDlFDEKlF ezhjRNYC3924CXaYxjmS3YbPCNjYS86bBl13gsvV1XmHK7A89j1RikLTylWsyVF0swaj Kc8g== 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=mymMN65KdMgVl3wAqg5NiaBMtjIpu5H8U2foaZl7zbw=; b=FP/1NjvdK61SQKuhIDU5A5DXevmFXHyW30d0wu8YgdP9L9JSztKAlZrFuAMOFKdslh Nn2CtLLzWpNKZ4FEnyBJMzBEa6225tJ5Czb9oQHHzIBN2FS5kutjnH7TZy5EABlKcCXd zgAWs4vdvlf7hmPpAS7gdGcC99ThckPW9HotVMGG5DN5wgSCv3UOYt0W8GCz4BZrspe6 oQWvL+7nq4cZtP0mXiu35pT7F6WIAjd53vVjLZGKGynXYzwhICKK+yZVKIHlMfiQ10fm cy7Co5UGCjUJOOuENDKzZX4yStNDaiaiLxhNFv0BqhmmxGHnp+qD/VSkFhAHoHZ0aP9y 3s/A== X-Gm-Message-State: AOAM533rgUkxzGtZ+/d7iDgsvSOEWDGf0jShRGAxsiSPVyxH67lKnklh tWe8vHzDkmU7W3o8R6EhESUPn9xr0Gt2PqxMVh4= X-Google-Smtp-Source: ABdhPJwaweLD7P3jIveXz34DeM8x5OPqnq2dOwvFXz4eD0v4g9P2g3N8i/ZvI0QSpz+/XV+zT84AafGQWZIaw38c5CU= X-Received: by 2002:a02:4b42:: with SMTP id q63mr4910596jaa.77.1607980768063; Mon, 14 Dec 2020 13:19:28 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> <9CDE8448-B4CD-4DC5-842D-3C58C5A322ED@mit.edu> In-Reply-To: From: Fabien Imbault Date: Mon, 14 Dec 2020 22:19:15 +0100 Message-ID: To: Warren Parad Cc: Justin Richer , Aaron Parecki , Dick Hardt , txauth gnap , Steve Moore Content-Type: multipart/alternative; boundary="0000000000007f0d6105b6733299" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 21:19:36 -0000 --0000000000007f0d6105b6733299 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Warren, The goal is not to force a behavior for the sake of forcing it, as Justin explained one of the goals is to avoid to the extra complexity of optionality when there's no fundamental reason for doing so. Which leaves open the question of which alternative is best of course, and that's what we're discussing here (security is not the only argument). Just wondering. If you're ready to hardcode the same value in every request in one case, why do you think better to have unique URIs in the other case? Plus the problem is not that you control the AS URI, it's that you have only limited trust for what's in front of that. A bound access token ensures that your call is anthenticated with the same key as before, while the alternative doesn't. Fabien Le lun. 14 d=C3=A9c. 2020 =C3=A0 21:41, Warren Parad a = =C3=A9crit : > So then I would say the question becomes, why force AS to create "access > tokens" (or whatever we want to call them) if they don't see the benefit = of > doing so. I.e. right now the Warren AS (and the Dick AS) both think we > would not be generating "access tokens". If the spec requires it, I would > probably just hard code the same value in every request because my AS > doesn't see the value in requiring it when I'm in control of the URI. > > If I understand the discussion correctly, we are trying to prevent AS fro= m > exposing the uri containing the "access token", because doing so would > hypothetically create an attack surface for the AS. If that's the case, > then I would say, forcing the token to be in auth header only provides a > negligible amount of surface decrease and thus the extra complexity is no= t > well offset by the security improvement. So for me rather than arguing if > there is any benefit at all, I'll make a stronger argument: > *If there is a benefit to using the access token, it surely can't be a > meaningful amount in such a way that it's important from the GNAP protoco= l > standpoint to provide this mechanism for improvement.* > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Mon, Dec 14, 2020 at 9:29 PM Justin Richer wrote: > >> Warren, >> >> (as editor): >> >> Your proposal below is not dissimilar to what=E2=80=99s in the current s= pec text: >> the URI is required, and the access token is optional. If the access tok= en >> is included, the client has to include it in its request. The feedback f= rom >> the working group during the IETF109 meeting, and leading up to it, was >> nearly universally that this optionality was not helpful, especially to >> client developers. The editors=E2=80=99 PR being discussed here removes = that >> optionality by making both fields required with only one method of >> presentation, and therefore a single code path for the client. >> >> =E2=80=94 Justin >> >> On Dec 14, 2020, at 3:11 PM, Warren Parad wrote: >> >> Here's a terrible alternative: >> >> It would seem to me that one compromise could be making the object >> extensible by authorization servers (and their corresponding SDK). In a >> similar way that JWTs are extensible, we could require explicitly the UR= I >> in the spec, and an optional object to be defined by the AS. >> >> -------- >> >> One source of the problem could be that the language for taking the >> response object and converting it back into a request one is not well >> defined. >> Instead if we allowed an optional headers object to be returned: >> { >> uri: "https://as/grant/{grantId}", >> headers: { >> 'Authorization': 'Bearer ${accessToken} >> } >> } >> >> Thereby explicitly telling the client what they need to return back. It >> avoids the problem of "what to name these things" and also ensures that = the >> data is exactly what the server expects. Additionally it sidesteps the >> naming issue, where to include tokens, and whether to include them at al= l. >> >> Otherwise it sucks to be in a situation where the benefits/detriments >> aren't clear to everyone, and potentially we can choose a path forward >> where both approaches could be used without requiring other clients to j= ump >> over arbritrary hurdles suchs as custom implementations. >> >> Warren Parad >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress . >> >> >> On Mon, Dec 14, 2020 at 8:46 PM Aaron Parecki wrote: >> >>> Thanks for the clear description. However saying "has no security >>> concerns" is a bold claim. Can you clarify how you will ensure that the= re >>> are no security concerns with this method? >>> >>> My main worry with this is people will start to get "creative" with the >>> values of the things in this URL. We've seen this over and over, everyt= hing >>> from using plaintext data in JWT access tokens in OAuth (now the access >>> token contents are visible to clients), to putting data in the OAuth >>> "state" parameter (easy to exploit unless it's signed/encrypted), and I= 'm >>> sure someone somewhere is putting things in the authorization code that >>> they shouldn't. >>> >>> Aaron >>> >>> >>> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt >>> wrote: >>> >>>> >>>> I am proposing a URI that is straight forward, and has no >>>> security concerns. >>>> >>>> For example, the URI could be: >>>> >>>> /grant/ >>>> >>>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >>>> >>>> The routing code in the AS then is: >>>> >>>> router.post( '/', grant.create); >>>> router.get( '/grant/:grant', grant.read); >>>> router.post( '/grant/:grant', grant.update); >>>> router.delete( '/grant/:grant', grant.delete); >>>> router.options( '/grant/:grant', grant.options); >>>> >>>> >>>> Where there is a "grant" module to manage for working with grant >>>> requests. >>>> >>>> /Dick >>>> >>>> ps: your previous email, and this one, are making the discussion >>>> personal. Happy to discuss privately. >>>> >>>> =E1=90=A7 >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >> >> >> --0000000000007f0d6105b6733299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Warren,

    T= he goal is not to force a behavior for the sake of forcing it, as Justin ex= plained one of the goals is to avoid to the extra complexity of optionality= when there's no fundamental reason for doing so. Which leaves open the= question of which alternative is best of course, and that's what we= 9;re discussing here (security is not the only argument).=C2=A0

    Just wondering. I= f you're ready to hardcode the same value in every request in one case,= why do you think better to have unique URIs in the other case?=C2=A0
    =

    Plus the problem is not that = you control the AS URI, it's that you have only limited trust for what&= #39;s in front of that. A bound access token ensures that your call is anth= enticated with the same key as before, while the alternative doesn't.= =C2=A0

    Fabien=C2=A0

    Le lun. 14 d=C3=A9c. 2020 =C3=A0 21:41, Warren Parad <wparad@rhosys.ch> a =C3=A9crit=C2=A0:<= br>
    So then I would sa= y the question becomes, why force AS to create "access tokens" (o= r whatever we want to call them) if they don't see the benefit of doing= so. I.e. right now the Warren AS (and the Dick AS) both think we would not= be generating "access tokens". If the spec requires it, I would = probably just hard code the same value in every request because my AS doesn= 't see the value in requiring it when I'm in control of the URI.
    If I understand the discussion correctly, we are trying to= prevent AS from exposing the uri containing the "access token", = because doing so would hypothetically create an attack surface=C2=A0for the= AS. If that's the case, then I would say, forcing the token to be in a= uth header only provides a negligible amount of surface decrease and thus t= he extra complexity is not well offset by the security improvement. So for = me rather than arguing if there is any benefit at all, I'll make a stro= nger argument:
    If there is a benefit to using the access token= , it surely can't be a meaningful amount in such a way that it's im= portant from the GNAP protocol standpoint to provide this mechanism for imp= rovement.

    <= /tbody>

    Warren Parad

    Founder, CTO

    Secure your user data and = complete your authorization architecture. Implement=C2=A0Authress.
    <= /div>


    On Mon, Dec 14, 2020 at 9:29 PM Justin Ric= her <jricher@mit.edu> wrote:
    Warren,

    (as editor):
    =
    Your proposal below is not dissimilar to what=E2=80=99s in t= he current spec text: the URI is required, and the access token is optional= . If the access token is included, the client has to include it in its requ= est. The feedback from the working group during the IETF109 meeting, and le= ading up to it, was nearly universally that this optionality was not helpfu= l, especially to client developers. The editors=E2=80=99 PR being discussed= here removes that optionality by making both fields required with only one= method of presentation, and therefore a single code path for the client.

    =C2=A0=E2=80=94 Justin

    On Dec 14, 2020, at 3:11 PM, Warren Parad <wparad@rh= osys.ch> wrote:

    = Here's a terrible alternative:

    It would seem to me = that one compromise could be making the object extensible by authorization = servers (and their corresponding SDK). In a similar way that JWTs are exten= sible, we could require explicitly the URI in the spec, and an optional obj= ect to be defined by the AS.

    --------

    =
    One source of the problem could be that the language for taking = the response object and converting it back into a request one is not well d= efined.
    Instead if we allowed an optional headers object to = be returned:
    {
    =C2=A0 =C2=A0 uri: "https://as/grant/= {grantId}",
    =C2=A0 =C2=A0 headers: {
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 'Authorization': 'Bearer ${accessToken}
    =C2=A0 =C2=A0= }
    }

    Thereby explicitly telling the client what= they need to return back. It avoids the problem of "what to name thes= e things" and also ensures that the data is exactly what the server ex= pects. Additionally it sidesteps the naming issue, where to include tokens,= and whether to include them at all.

    Otherwise it = sucks to be in a situation where the benefits/detriments aren't clear t= o everyone, and potentially we can choose a path forward where both approac= hes could be used without requiring other clients to jump over arbritrary= =C2=A0hurdles suchs as custom implementations.

    =
    		Warren Parad
    Founder, CTO
    Secure your user data and co= mplete your authorization architecture. Implement=C2=A0Authress.


    On Mon, Dec 14= , 2020 at 8:46 PM Aaron Parecki <aaron@parecki.com> wrote:
    Thanks= for the clear description. However saying "has no security concerns&q= uot; is a bold claim. Can you clarify how you will ensure that there are no= security concerns with this method?

    My main worry with = this is people will start to get "creative" with the values of th= e things in this URL. We've seen this over and over, everything from us= ing plaintext data in JWT access tokens in OAuth (now the access token cont= ents are visible to clients), to putting data in the OAuth "state"= ; parameter (easy to exploit unless it's signed/encrypted), and I'm= sure someone somewhere is putting things in the authorization code that th= ey shouldn't.

    Aaron

    =
    On Mon= , Dec 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wr= ote:

    I am proposing a URI that is straight forward, an= d has no security=C2=A0concerns.

    For example, the = URI could be:

    <as uri>/grant/<unique gran= t id>


    The routing code in the AS then is= :

    router.post(=C2=A0 =C2=A0 =C2=A0 '/', grant.create);=
    router.get(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.r= ead);
    router.post(=C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.upda= te);
    router.delete(=C2=A0 =C2=A0'/grant/:grant', grant.delete);<= br>router.options( '/grant/:grant', grant.options);

    Where there is a "grant" module to manage for wo= rking with grant requests.

    /Dick

    ps: your previous email, and this one, are making the discussion pe= rsonal. Happy to discuss privately.

    3D""=E1= =90=A7
    --=C2=A0
    TXAuth mailing list
    TXAuth@iet= f.org
    https://www.ietf.org/mailman/l= istinfo/txauth
    --=C2=A0
    TXAuth ma= iling list
    TXAuth@ietf.org
    https://www= .ietf.org/mailman/listinfo/txauth
    =

    --0000000000007f0d6105b6733299-- From nobody Mon Dec 14 13:25:58 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849203A1330 for ; Mon, 14 Dec 2020 13:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jkd2etfSqPr for ; Mon, 14 Dec 2020 13:25:50 -0800 (PST) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 D65033A132D for ; Mon, 14 Dec 2020 13:25:49 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id b9so24670147ejy.0 for ; Mon, 14 Dec 2020 13:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=94RLtruN3Sn3WxXCedSZH9yKLJoU1DAXcrqp67TmSAY=; b=ABmUn60mUWA4AgFciyxmWpn2fHk9884FXaE+9k5FYMSh6Hz48zW2ALznYrHZcFZcGy WMKG2Bo1X5eg2eS/d5ASfoAlUVLhA6iD81y4HiJQZ6wj6rKJejl8dL/wbnWpaTW1V+W4 F+ldDqC+6gdzdRnJm6UR6tgCxq9OgcJfKTnq4= 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=94RLtruN3Sn3WxXCedSZH9yKLJoU1DAXcrqp67TmSAY=; b=F4RfJWvlAUCDKGKG3aUrsTeeQe8n+uIa+V8riYzhUAk3L7dAlU+bIaz3Py3R/diV5A D3GNYnoOEDQ0KohlxMI+9vx5wrgQW8c35OvgRyJiGsl3V0z5BlXBPI0CLvL6KFwkwoPU zSFCQ+6CqrOqMAZ8zOs5Ao5fqu0hCT5gipuvvTBDEGa+gUI5IyZEGj23ZyG8c0MDG8Jo 7v6w3ncbBEWia5dY8mO2XFGPhZ2zVQhY4rY+EsnSG9DOFxoNHPV2s/Y0PdKxWmYHBwWy 6JqVuYUcaIBsMGZGHq6hzH1LmNwyjPe45H4YYgu9vdeVbN8nJJsPmKJwwlKHVx8bOqbz agwg== X-Gm-Message-State: AOAM533ES/6aUQ707R2NKaeBo1Ecmw0maSBXn+54YieVDL8ynF6lWCDx 6liTn1JNsfFRpiM9Drh4/tueWjtdzaC9bWuDhF1/POIAbpwM7Mp4x8fSWIfvqNsg5G+lTsOfdhC yQRDAm2NoLslEne0= X-Google-Smtp-Source: ABdhPJzxc90KunX0SlspTgecO1I7edel09cSYGihnP2WVx4zyV7Mp47sPDJUtyMTtTknrGSe09318P2lvCQ5r/MdMz0= X-Received: by 2002:a17:906:cec3:: with SMTP id si3mr3179106ejb.277.1607981147972; Mon, 14 Dec 2020 13:25:47 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Dave Tonge Date: Mon, 14 Dec 2020 22:25:36 +0100 Message-ID: To: Dick Hardt Cc: Aaron Parecki , Fabien Imbault , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="0000000000002184dc05b6734973" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 21:25:55 -0000 --0000000000002184dc05b6734973 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On the call I voiced my opinion that opionality should be reduced in the spec where possible. At the time I was in favour of access tokens being required. However, after reading the thread and looking again at the spec I'm no longer convinced. The only advantage I can see of the access token, is that it provides a way for the AS to be stateless, but I'm not sure how common or desirable that use-case is? As soon as the AS has to look some information up about a grant in order to continue, then there is no benefit in the access token. The identity of the grant can be in the url, and the authenticity of the client is provided by the signature. I know this is beyond the scope of this pull request, but for the majority of use-cases, my personal opinion is that a consistent identifier for each grant and a mandated REST like URL structure would be far more useful. The GNAP spec is being designed in an extensible manner that will allow a huge amount of use cases. Maybe in the future there will be new endpoints dreamed up at the AS that require tokens. But the current ones described in the spec don't (create grant, continue grant, modify grant, get grant, cancel grant, rotate token & revoke token). I also think there is some confusion that "binding" is being used for: - client authentication - sender constraining access tokens - http request signing If the signing mechanism is ok to authenticate the client in the first request, why is it not sufficient to authenticate the client on the continuation request? I think we need a stronger use-case for access tokens at the AS to warrant even its optional inclusion in the spec. On Mon, 14 Dec 2020 at 21:25, Dick Hardt wrote: > I don't understand what security risks are unique with the GNAP URI > relative to other API URIs that have a unique identifier in them. > > Developers can get "creative" and put "inappropriate" values in any API > URI they design. > > What are the security implications of using a large random value as the > ? > > > =E1=90=A7 > > On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki wrote: > >> Thanks for the clear description. However saying "has no security >> concerns" is a bold claim. Can you clarify how you will ensure that ther= e >> are no security concerns with this method? >> >> My main worry with this is people will start to get "creative" with the >> values of the things in this URL. We've seen this over and over, everyth= ing >> from using plaintext data in JWT access tokens in OAuth (now the access >> token contents are visible to clients), to putting data in the OAuth >> "state" parameter (easy to exploit unless it's signed/encrypted), and I'= m >> sure someone somewhere is putting things in the authorization code that >> they shouldn't. >> >> Aaron >> >> >> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt wrote= : >> >>> >>> I am proposing a URI that is straight forward, and has no >>> security concerns. >>> >>> For example, the URI could be: >>> >>> /grant/ >>> >>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >>> >>> The routing code in the AS then is: >>> >>> router.post( '/', grant.create); >>> router.get( '/grant/:grant', grant.read); >>> router.post( '/grant/:grant', grant.update); >>> router.delete( '/grant/:grant', grant.delete); >>> router.options( '/grant/:grant', grant.options); >>> >>> >>> Where there is a "grant" module to manage for working with grant >>> requests. >>> >>> /Dick >>> >>> ps: your previous email, and this one, are making the discussion >>> personal. Happy to discuss privately. >>> >>> =E1=90=A7 >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --0000000000002184dc05b6734973 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On the call I voiced my opinion that opionality should be = reduced in the spec where possible. At the time I was in favour of access t= okens being required. However, after reading the thread and looking again a= t the spec I'm no longer convinced.

    The only advantage I= can see of the access token, is that it provides a way for the AS to be st= ateless, but I'm not sure how common or desirable that use-case is? As = soon as the AS has to look some information up about a grant in order to co= ntinue, then there is no benefit in the access token. The identity of the g= rant can be in the url, and the authenticity of the client is provided by t= he signature.=C2=A0=C2=A0

    I know this is beyond the scope of= this pull request, but for the majority of use-cases, my personal opinion = is that a consistent identifier for each grant and a mandated REST like URL= structure would be far more useful.=C2=A0

    The GNAP spec is = being designed in an extensible manner that will allow a huge amount=C2=A0o= f use cases. Maybe in the future there will be new endpoints dreamed up at = the AS that require tokens. But the current ones described in=C2=A0 the spe= c don't (create grant, continue grant, modify grant, get grant, cancel = grant, rotate token & revoke token).

    I also think = there is some confusion that "binding" is being used for:
    = =C2=A0- client authentication
    =C2=A0- sender constraining access token= s
    =C2=A0- http request signing

    If the signing mechanism= is ok to authenticate the client in the first request, why is it not suffi= cient to authenticate the client on the continuation request?

    On Mon, 14 Dec 2020 = at 21:25, Dick Hardt <dick.hardt@gmail.com> wrote:
    I don't understand what se= curity risks are unique with the GNAP URI relative to other API URIs that= =C2=A0have a unique identifier=C2=A0in them.=C2=A0

    D= evelopers can get "creative" and put "inappropriate" va= lues in any API URI they design.

    What are the secu= rity implications of using a large random value as the <unique grant id&= gt;?


    3D""=E1=90=A7

    On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki <aaron@parecki.com> wrote:
    =
    Thanks f= or the clear description. However saying "has no security concerns&quo= t; is a bold claim. Can you clarify how you will ensure that there are no s= ecurity concerns with this method?

    My main worry with th= is is people will start to get "creative" with the values of the = things in this URL. We've seen this over and over, everything from usin= g plaintext data in JWT access tokens in OAuth (now the access token conten= ts are visible to clients), to putting data in the OAuth "state" = parameter (easy to exploit unless it's signed/encrypted), and I'm s= ure someone somewhere is putting things in the authorization code that they= shouldn't.

    Aaron

    On Mon, = Dec 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    =
    I am proposing a URI that is straight forward, and has no security=C2= =A0concerns.

    For example, the URI could be:
    <= div>
    <as uri>/grant/<unique grant id>
    <= br>

    The routing code= in the AS then is:

    router.post(=C2=A0 =C2=A0 =C2=A0 '/', grant.create);router.get(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.rea= d);
    router.post(=C2= =A0 =C2=A0 =C2=A0 '/grant/:grant', grant.update);
    router.delete(= =C2=A0 =C2=A0'/grant/:grant', grant.delete);
    router.options( = 9;/grant/:grant', grant.options);

    Where= there is a "grant" module to manage for working with grant reque= sts.

    /Dick

    ps: your previ= ous email, and this one, are making the discussion personal. Happy to discu= ss privately.

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --0000000000002184dc05b6734973-- From nobody Mon Dec 14 14:21:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36843A0F02 for ; Mon, 14 Dec 2020 14:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZNGQ3u8Atfg for ; Mon, 14 Dec 2020 14:21:41 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8043A0F00 for ; Mon, 14 Dec 2020 14:21:41 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id z136so18522559iof.3 for ; Mon, 14 Dec 2020 14:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KQf1Uf4xqypup8o70V3jfOKtXZluQn1vI3MUzoV2xAg=; b=O5EKxQrt3+8HjapRZXkweuRknQ7hFmWtPsCL/qXOJh+Yb3Af7HsuxXuleb/+Kx8a5y bgz3TPoSzdNCDDZEIU0/ta64UEdrzYtPxoEcxdftTXlujiHNQtwBDt6Z5hETuclR0MCy FS2pRM4SlH8pxbhs/rkiC/+exH855EaY4dZhY= 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=KQf1Uf4xqypup8o70V3jfOKtXZluQn1vI3MUzoV2xAg=; b=T1qVEkeNH2SkfqRKfWQfn9nukNvs6lo2G+VLmQHgMRdZC6VDD75gGrK5JZt49EOw/f 6lUusmLOtuCMCQ9oyYN/n2QI/N9IsI80x1BDuzuthzNt+gW7dQYont3MwJdpAoAMrjN3 BW8YT4irwa3AflzzLTo/PNzbczfx+oMXJRYvDlV56g3xtVgP0YoTt2cFNcmvub1YhWdv K+GtHQRdZbIlz3r7Y9oWnQaUlurvwuX04QqIDfeCunGXjwr7phSDiu+YcDORRJMx4pwb jFHXC0TRjDjMusxaIm/EdauxXn+eH/i0gCej8qY8uREJPgojzz4DyxNue/rRfMSaxPBl xikQ== X-Gm-Message-State: AOAM532H/VDeNAh6zUBCtW07eLIlmsgp4DeIeOaEGtQJ5++YRTxEfHlP X+wyaxC3iOMGlOWZDtz7jTNLTTJDk50VOtuIJe5f X-Google-Smtp-Source: ABdhPJxONKQgz/PBQSwqKYJhkWtElz2WknS79SE1gnsAk7mtOEo66IMui90X+QcxFaR6Bg5hSVhHUSLCB0WZmpec1Dw= X-Received: by 2002:a02:3541:: with SMTP id y1mr35126987jae.66.1607984500230; Mon, 14 Dec 2020 14:21:40 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Warren Parad Date: Mon, 14 Dec 2020 23:21:28 +0100 Message-ID: To: Dave Tonge Cc: Dick Hardt , Fabien Imbault , Stephen Moore , txauth gnap , Aaron Parecki , Justin Richer Content-Type: multipart/alternative; boundary="000000000000f0e6e305b6741003" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 14 Dec 2020 22:21:44 -0000 --000000000000f0e6e305b6741003 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Based on the information shared, my preference would be to call the "access token", *session token*, I'll continue to do so in further communication. It's really how it's being used and now I can understand why conversation about cookies has come up. The "access token" is a session token, and session tokens have historically been transmitted via cookies, but in this case we are looking to transfer session token via the authorization header. > And the AS can still look up the client=E2=80=99s instance information b= ased on > that request, just like any RS with access to that information would be > able to If the AS can use the existing information in the request to look up the client to ensure it is the same party, the question for me is "Why wouldn't it?". What's the benefit of changing the auth mechanism between the first call and subsequent ones to identify the calling party? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Mon, Dec 14, 2020 at 10:26 PM Dave Tonge wrote= : > On the call I voiced my opinion that opionality should be reduced in the > spec where possible. At the time I was in favour of access tokens being > required. However, after reading the thread and looking again at the spec > I'm no longer convinced. > > The only advantage I can see of the access token, is that it provides a > way for the AS to be stateless, but I'm not sure how common or desirable > that use-case is? As soon as the AS has to look some information up about= a > grant in order to continue, then there is no benefit in the access token. > The identity of the grant can be in the url, and the authenticity of the > client is provided by the signature. > > I know this is beyond the scope of this pull request, but for the majorit= y > of use-cases, my personal opinion is that a consistent identifier for eac= h > grant and a mandated REST like URL structure would be far more useful. > > The GNAP spec is being designed in an extensible manner that will allow a > huge amount of use cases. Maybe in the future there will be new endpoints > dreamed up at the AS that require tokens. But the current ones described > in the spec don't (create grant, continue grant, modify grant, get grant= , > cancel grant, rotate token & revoke token). > > I also think there is some confusion that "binding" is being used for: > - client authentication > - sender constraining access tokens > - http request signing > > If the signing mechanism is ok to authenticate the client in the first > request, why is it not sufficient to authenticate the client on the > continuation request? > > I think we need a stronger use-case for access tokens at the AS to > warrant even its optional inclusion in the spec. > > On Mon, 14 Dec 2020 at 21:25, Dick Hardt wrote: > >> I don't understand what security risks are unique with the GNAP URI >> relative to other API URIs that have a unique identifier in them. >> >> Developers can get "creative" and put "inappropriate" values in any API >> URI they design. >> >> What are the security implications of using a large random value as the >> ? >> >> >> =E1=90=A7 >> >> On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki wrote= : >> >>> Thanks for the clear description. However saying "has no security >>> concerns" is a bold claim. Can you clarify how you will ensure that the= re >>> are no security concerns with this method? >>> >>> My main worry with this is people will start to get "creative" with the >>> values of the things in this URL. We've seen this over and over, everyt= hing >>> from using plaintext data in JWT access tokens in OAuth (now the access >>> token contents are visible to clients), to putting data in the OAuth >>> "state" parameter (easy to exploit unless it's signed/encrypted), and I= 'm >>> sure someone somewhere is putting things in the authorization code that >>> they shouldn't. >>> >>> Aaron >>> >>> >>> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt >>> wrote: >>> >>>> >>>> I am proposing a URI that is straight forward, and has no >>>> security concerns. >>>> >>>> For example, the URI could be: >>>> >>>> /grant/ >>>> >>>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >>>> >>>> The routing code in the AS then is: >>>> >>>> router.post( '/', grant.create); >>>> router.get( '/grant/:grant', grant.read); >>>> router.post( '/grant/:grant', grant.update); >>>> router.delete( '/grant/:grant', grant.delete); >>>> router.options( '/grant/:grant', grant.options); >>>> >>>> >>>> Where there is a "grant" module to manage for working with grant >>>> requests. >>>> >>>> /Dick >>>> >>>> ps: your previous email, and this one, are making the discussion >>>> personal. Happy to discuss privately. >>>> >>>> =E1=90=A7 >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f0e6e305b6741003 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Based on the information shared, my preference would = be to call the "access token", session token, I'll con= tinue to do so in further communication. It's really how it's being= used and now I can understand why conversation about cookies has come up. = The "access token" is a session token, and session tokens have hi= storically been transmitted via cookies, but in this case we are looking to= transfer session token via the authorization header.
    =C2=A0
    =C2=A0And the AS can sti= ll look up the client=E2=80=99s instance information based on that request,= just like any RS with access to that information would be able to

    If the AS can use the existing information in the r= equest to look up the client to ensure it is the same party, the question f= or me is "Why wouldn't it?".

    What= 9;s the benefit of changing the auth mechanism between the first call and s= ubsequent ones to identify the calling party?
    =C2=A0
    Secure your user data and complete you= r authorization architecture. Implement=C2=A0Authress.

    =
    On Mon= , Dec 14, 2020 at 10:26 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    On the call I= voiced my opinion that opionality should be reduced in the spec where poss= ible. At the time I was in favour of access tokens being required. However,= after reading the thread and looking again at the spec I'm no longer c= onvinced.

    The only advantage I can s= ee of the access token, is that it provides a way for the AS to be stateles= s, but I'm not sure how common or desirable that use-case is? As soon a= s the AS has to look some information up about a grant in order to continue= , then there is no benefit in the access token. The identity of the grant c= an be in the url, and the authenticity of the client is provided by the sig= nature.=C2=A0=C2=A0

    I know this is b= eyond the scope of this pull request, but for the majority of use-cases, my= personal opinion is that a consistent identifier for each grant and a mand= ated REST like URL structure would be far more useful.=C2=A0

    The GNAP spec is being designed in an extensible m= anner that will allow a huge amount=C2=A0of use cases. Maybe in the future = there will be new endpoints dreamed up at the AS that require tokens. But t= he current ones described in=C2=A0 the spec don't (create grant, contin= ue grant, modify grant, get grant, cancel grant, rotate token & revoke = token).

    I also thi= nk there is some confusion that "binding" is being used for:
    =C2=A0- client authentication
    =C2=A0- sender = constraining access tokens
    =C2=A0- http request signing

    If the signing mechanism is ok to auth= enticate the client in the first request, why is it not sufficient to authe= nticate the client on the continuation request?

    =
    I think we need a stronger use-case for access tokens at the AS= to warrant=C2=A0even its optional inclusion in the spec.

    On Mon, 14 D= ec 2020 at 21:25, Dick Hardt <dick.hardt@gmail.com> wrote:
    I don't understand= what security risks are unique with the GNAP URI relative to other API URI= s that=C2=A0have a unique identifier=C2=A0in them.=C2=A0

    =
    Developers can get "creative" and put "inappropriate&qu= ot; values in any API URI they design.

    What are th= e security implications of using a large random value as the <unique gra= nt id>?


    3D""=E1=90=A7

    On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki <aaron@parecki.com> wrote:
    Thank= s for the clear description. However saying "has no security concerns&= quot; is a bold claim. Can you clarify how you will ensure that there are n= o security concerns with this method?

    My main worry with= this is people will start to get "creative" with the values of t= he things in this URL. We've seen this over and over, everything from u= sing plaintext data in JWT access tokens in OAuth (now the access token con= tents are visible to clients), to putting data in the OAuth "state&quo= t; parameter (easy to exploit unless it's signed/encrypted), and I'= m sure someone somewhere is putting things in the authorization code that t= hey shouldn't.

    Aaron


    On Mo= n, Dec 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:

    I am proposing a URI that is straight forward, and has no security= =C2=A0concerns.

    For example, the URI could be:

    <as uri>/grant/<unique grant id>


    The routing c= ode in the AS then is:

    router.post(=C2=A0 =C2=A0 =C2=A0 '/', grant.create)= ;
    router.get(=C2=A0 =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.= read);
    router.post(= =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.update);
    router.dele= te(=C2=A0 =C2=A0'/grant/:grant', grant.delete);
    router.options( = '/grant/:grant', grant.options);

    Wh= ere there is a "grant" module to manage for working with grant re= quests.

    /Dick

    ps: your pr= evious email, and this one, are making the discussion personal. Happy to di= scuss privately.

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5t= h Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2= =A0+44 (0)117 28= 0 5120

    =
    Moneyhub Enterprise is a trading style of Moneyhub F= inancial Technology Limited which is authorised and regulated by the Financ= ial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology= is entered on the Financial Services Register=C2=A0(FRN= =C2=A0809360) at https://register.fca.= org.uk/. Moneyhub=C2=A0Financial Technology is registe= red in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000f0e6e305b6741003-- From nobody Mon Dec 14 16:37:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80C23A1111 for ; Mon, 14 Dec 2020 16:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBz2pbty7EKF for ; Mon, 14 Dec 2020 16:37:12 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7713A1106 for ; Mon, 14 Dec 2020 16:37:12 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id t9so17618012ilf.2 for ; Mon, 14 Dec 2020 16:37:12 -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=uwZv8oy+wv4MjhH8nu0IX9MJzDxgbVgpSYCanB4W9Ao=; b=sU1c6zwohl4PIbOXyVnNKI9wouZLeKGbQJ+KLZOffBpPQNBjnp+nXd18xepU5li55v uU0HpIiz+eDjcKGbpFge2VnGSRyVJPx54bDPt8xBTfd2/V3ihl+RFbR71AhGMULiT1a/ Vzq4DDPWMJKBjjAAYFu4N/ERS5e8YQJDF75m5nWh+5DDYVdbImYLEeDoHVK63ffT1IbT h5qpd7+ylCJeugk8gK+Snh1m2lvWk47wkIwiGeWYvN4BKTU7ZVTJZzmy/Q5i3gfqyoXJ WKkDs9Py1k8CDREnteN26BMVoAoEg1VrmYuYZLjwXeHrKvNcjsCIwxGf+hjEdX82UEBd ouNg== 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=uwZv8oy+wv4MjhH8nu0IX9MJzDxgbVgpSYCanB4W9Ao=; b=Z/gvwoFJa9PU9xt3D6ugcN6FW602nYcaPk7p0U+Gh4of28aJM1qsH8TsTDDOlLbDzN mtiotXelTphILre3E1HwmadhZcEQMppARcqUJ/P9oLAGs5NWKSoOa7QnNEPpCMHan89m Yupjuyxu9T4uEkDUZPO5Nu2R2KH9c94tapgQ01LJ6B5lW8eErTotM92Rg7h7YlXITwAf ya+lquTvcnxkb7X2EcJPhwNAuMCWZhK6PxmeY08m08dFmH8jOXTXnN8EE1GCab55zq6p pir0Of+TyFRaeXsoG8eZjl5/UqnEi0KwZtBMEHy4oR9rvCI0k3epTlymZxLHqaCKrbg7 HzZQ== X-Gm-Message-State: AOAM533Mwcpt2UqbElgvwlI9sUV+kSBWBxGZVFFP9J4loIgmOqKGGc4b p4jJazpqyaxDIPxTjBtvONe/Abw15Vs41LSKFY0= X-Google-Smtp-Source: ABdhPJwr4TtE+9AHKnC4NkOOOET3nFwXksjlSj4vUMVDhlsDO4kgWCbl87eLmsqH6z1MLonAZp89aKUsYAM2jf3kuBU= X-Received: by 2002:a92:aa4c:: with SMTP id j73mr37372255ili.123.1607992631875; Mon, 14 Dec 2020 16:37:11 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Fabien Imbault Date: Tue, 15 Dec 2020 01:36:59 +0100 Message-ID: To: Warren Parad Cc: Dave Tonge , Dick Hardt , Stephen Moore , txauth gnap , Aaron Parecki , Justin Richer Content-Type: multipart/alternative; boundary="0000000000009fdcc905b675f52e" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 00:37:16 -0000 --0000000000009fdcc905b675f52e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's not acting as a session id, as least not in the way you describe it. A big difference is that you may encode (and encrypt) the content of the access token, so it may for instance : - indicate a start time and end time for the request - specify a client instance and maybe a dynamic client posture - and contain any other info the server may wish to embed - plus this is bound to a key which might be rotated if needed So it's really a token, with a content and format that is fully opaque to the client. That answers to your question "why wouldn't it?". Because you have a more powerful and generic mechanism using tokens. But since you're referring to sessions, it gives you one hint on the difference between the initial request and the continuations. Of course at the initialization, there's no server state yet. Le lun. 14 d=C3=A9c. 2020 =C3=A0 23:21, Warren Parad a = =C3=A9crit : > Based on the information shared, my preference would be to call the > "access token", *session token*, I'll continue to do so in further > communication. It's really how it's being used and now I can understand w= hy > conversation about cookies has come up. The "access token" is a session > token, and session tokens have historically been transmitted via cookies, > but in this case we are looking to transfer session token via the > authorization header. > > >> And the AS can still look up the client=E2=80=99s instance information = based on >> that request, just like any RS with access to that information would be >> able to > > > If the AS can use the existing information in the request to look up the > client to ensure it is the same party, the question for me is "Why wouldn= 't > it?". > > What's the benefit of changing the auth mechanism between the first call > and subsequent ones to identify the calling party? > > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Mon, Dec 14, 2020 at 10:26 PM Dave Tonge > wrote: > >> On the call I voiced my opinion that opionality should be reduced in the >> spec where possible. At the time I was in favour of access tokens being >> required. However, after reading the thread and looking again at the spe= c >> I'm no longer convinced. >> >> The only advantage I can see of the access token, is that it provides a >> way for the AS to be stateless, but I'm not sure how common or desirable >> that use-case is? As soon as the AS has to look some information up abou= t a >> grant in order to continue, then there is no benefit in the access token= . >> The identity of the grant can be in the url, and the authenticity of the >> client is provided by the signature. >> >> I know this is beyond the scope of this pull request, but for the >> majority of use-cases, my personal opinion is that a consistent identifi= er >> for each grant and a mandated REST like URL structure would be far more >> useful. >> >> The GNAP spec is being designed in an extensible manner that will allow = a >> huge amount of use cases. Maybe in the future there will be new endpoint= s >> dreamed up at the AS that require tokens. But the current ones described >> in the spec don't (create grant, continue grant, modify grant, get gran= t, >> cancel grant, rotate token & revoke token). >> >> I also think there is some confusion that "binding" is being used for: >> - client authentication >> - sender constraining access tokens >> - http request signing >> >> If the signing mechanism is ok to authenticate the client in the first >> request, why is it not sufficient to authenticate the client on the >> continuation request? >> >> I think we need a stronger use-case for access tokens at the AS to >> warrant even its optional inclusion in the spec. >> >> On Mon, 14 Dec 2020 at 21:25, Dick Hardt wrote: >> >>> I don't understand what security risks are unique with the GNAP URI >>> relative to other API URIs that have a unique identifier in them. >>> >>> Developers can get "creative" and put "inappropriate" values in any API >>> URI they design. >>> >>> What are the security implications of using a large random value as the >>> ? >>> >>> >>> =E1=90=A7 >>> >>> On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki >>> wrote: >>> >>>> Thanks for the clear description. However saying "has no security >>>> concerns" is a bold claim. Can you clarify how you will ensure that th= ere >>>> are no security concerns with this method? >>>> >>>> My main worry with this is people will start to get "creative" with th= e >>>> values of the things in this URL. We've seen this over and over, every= thing >>>> from using plaintext data in JWT access tokens in OAuth (now the acces= s >>>> token contents are visible to clients), to putting data in the OAuth >>>> "state" parameter (easy to exploit unless it's signed/encrypted), and = I'm >>>> sure someone somewhere is putting things in the authorization code tha= t >>>> they shouldn't. >>>> >>>> Aaron >>>> >>>> >>>> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt >>>> wrote: >>>> >>>>> >>>>> I am proposing a URI that is straight forward, and has no >>>>> security concerns. >>>>> >>>>> For example, the URI could be: >>>>> >>>>> /grant/ >>>>> >>>>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >>>>> >>>>> The routing code in the AS then is: >>>>> >>>>> router.post( '/', grant.create); >>>>> router.get( '/grant/:grant', grant.read); >>>>> router.post( '/grant/:grant', grant.update); >>>>> router.delete( '/grant/:grant', grant.delete); >>>>> router.options( '/grant/:grant', grant.options); >>>>> >>>>> >>>>> Where there is a "grant" module to manage for working with grant >>>>> requests. >>>>> >>>>> /Dick >>>>> >>>>> ps: your previous email, and this one, are making the discussion >>>>> personal. Happy to discuss privately. >>>>> >>>>> =E1=90=A7 >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6= FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000009fdcc905b675f52e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It's not acting as a session id, as= least not in the way you describe it.=C2=A0

    A big difference is that you may encode (and encrypt) = the content of the access token, so it may for instance :
    - indicate a start time and end time for the request=C2=A0
    - specify a client instance and maybe a dynamic client posture=
    - and contain any other info the server may wish to= embed
    - plus this is bound to a key which might be = rotated if needed=C2=A0

    = So it's really a token, with a content and format that is fully opaque = to the client. That answers to your question "why wouldn't it?&quo= t;. Because you have a more powerful and generic mechanism using tokens.=C2= =A0

    But since you're= referring to sessions, it gives you one hint on the difference between the= initial request and the continuations. Of course at the initialization, th= ere's no server state yet.=C2=A0


    Le lun. 14 d=C3=A9c. 2= 020 =C3=A0 23:21, Warren Parad <wpar= ad@rhosys.ch> a =C3=A9crit=C2=A0:
    Based on the information shared, my preference = would be to call the "access token", session token, I'= ll continue to do so in further communication. It's really how it's= being used and now I can understand why conversation about cookies has com= e up. The "access token" is a session token, and session tokens h= ave historically been transmitted via cookies, but in this case we are look= ing to transfer session token via the authorization header.
    =C2= =A0
    =C2=A0And the AS= can still look up the client=E2=80=99s instance information based on that = request, just like any RS with access to that information would be able to<= /blockquote>

    If the AS can use the existing information = in the request to look up the client to ensure it is the same party, the qu= estion for me is "Why wouldn't it?".

    What's the benefit of changing the auth mechanism between the first ca= ll and subsequent ones to identify the calling party?
    =C2=A0
    <= /div>

    =

    Warren Parad

    Founder, CTO

    Warren= Parad

    = Founder, CTO

    Secure your user data and complete your authorization archit= ecture. Implement=C2=A0Authress.

    On Mon, D= ec 14, 2020 at 10:26 PM Dave Tonge <dave.tonge@moneyhub.com>= wrote:
    On the call I voiced my opinion that opionality should= be reduced in the spec where possible. At the time I was in favour of acce= ss tokens being required. However, after reading the thread and looking aga= in at the spec I'm no longer convinced.

    The only advantage I can see of the access token, is that it provid= es a way for the AS to be stateless, but I'm not sure how common or des= irable that use-case is? As soon as the AS has to look some information up = about a grant in order to continue, then there is no benefit in the access = token. The identity of the grant can be in the url, and the authenticity of= the client is provided by the signature.=C2=A0=C2=A0

    =
    I know this is beyond the scope of this pull request, but= for the majority of use-cases, my personal opinion is that a consistent id= entifier for each grant and a mandated REST like URL structure would be far= more useful.=C2=A0

    The GNAP spec is= being designed in an extensible manner that will allow a huge amount=C2=A0= of use cases. Maybe in the future there will be new endpoints dreamed up at= the AS that require tokens. But the current ones described in=C2=A0 the sp= ec don't (create grant, continue grant, modify grant, get grant, cancel= grant, rotate token & revoke token).
    I also think there is some confusion that "bin= ding" is being used for:
    =C2=A0- client authenticatio= n
    =C2=A0- sender constraining access tokens
    =C2=A0- http request signing

    If t= he signing mechanism is ok to authenticate the client in the first request,= why is it not sufficient to authenticate the client on the continuation re= quest?

    I think we need a stronger us= e-case for access tokens at the AS to warrant=C2=A0even its optional inclus= ion in the spec.

    On Mon, 14 Dec 2020 at 21:25, Dick Hardt <dick.= hardt@gmail.com> wrote:
    I don't understand what security risks = are unique with the GNAP URI relative to other API URIs that=C2=A0have a un= ique identifier=C2=A0in them.=C2=A0

    Developers can g= et "creative" and put "inappropriate" values in any API= URI they design.

    What are the security implicatio= ns of using a large random value as the <unique grant id>?
    =

    3D""=E1=90=A7

    On Mon, Dec 14, 2020= at 11:46 AM Aaron Parecki <aaron@parecki.com> wrote:
    Thanks for= the clear description. However saying "has no security concerns"= is a bold claim. Can you clarify how you will ensure that there are no sec= urity concerns with this method?

    My main worry with this= is people will start to get "creative" with the values of the th= ings in this URL. We've seen this over and over, everything from using = plaintext data in JWT access tokens in OAuth (now the access token contents= are visible to clients), to putting data in the OAuth "state" pa= rameter (easy to exploit unless it's signed/encrypted), and I'm sur= e someone somewhere is putting things in the authorization code that they s= houldn't.

    Aaron


    =
    On Mon, De= c 14, 2020 at 11:39 AM Dick Hardt <dick.hardt@gmail.com> wrote:=

    I am proposing a URI that is straight forward, and ha= s no security=C2=A0concerns.

    For example, the URI = could be:

    <as uri>/grant/<unique grant id= >

    <= div>
    The routing code in the AS then is:

    =
    router.post<= /a>(=C2=A0 =C2=A0 =C2=A0 '/', grant.create);
    router.get(=C2=A0 = =C2=A0 =C2=A0 =C2=A0 '/grant/:grant', grant.read);
    router.post(=C2= =A0 =C2=A0 =C2=A0 '/grant/:grant', grant.update);
    router.delete(= =C2=A0 =C2=A0'/grant/:grant', grant.delete);
    router.options( = 9;/grant/:grant', grant.options);

    Where= there is a "grant" module to manage for working with grant reque= sts.

    /Dick

    ps: your previ= ous email, and this one, are making the discussion personal. Happy to discu= ss privately.

    3D""=E1=90=A7
    --
    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>


    --

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

    A = potentially-rotating URI would be just as brittle, and so having a = single codified identifier for this artifact would be useful, but it = does assume some things about the nature of the AS. Every other use the = client has to manage the ongoing request over time doesn=E2=80=99t need = an explicit identifier. Just like with OAuth-protected APIs, the server = can determine the context not just from the URI but from the rest of the = request, including the access token itself. This is both more common and = more powerful than a strict reading of REST designs. It also follows the = HATEOS principles as the entire HTTP request is taken into account, = including the access token and signature portions. 

    I=E2=80=99ll also point = out that the rotation of these credentials is also filed as a separate = issue that=E2=80=99s not being addressed right now, so we can revisit = that discussion separately:

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

    As for the = name, we could give it a different label. We have this same pattern of = issuing a resource-specific access token alongside a URL in the Dynamic = Registration specification, both in OAuth (https://tools.ietf.org/html/rfc7592#section-3) and OpenID = Connect (https://openid.net/specs/openid-connect-registration-1_0.html#R= egistrationResponse). Here it=E2=80=99s called the =E2=80=9Cregistrati= on access token=E2=80=9D =E2=80=94 but what=E2=80=99s important there, = as it is here, is that it=E2=80=99s not a different kind of artifact = that the client now has to figure out how to use, it=E2=80=99s an access = token plain and simple. In the OAuth world this is a bearer token, since = that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll be a = bound token, as that=E2=80=99s what we=E2=80=99re looking to build on. = This is also related to another future discussion about responses tying = an access token to a specific API that=E2=80=99s told to the client, as = we could potentially re-use those components and concepts here as = well:

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

    And finally, = no speculation on the complexity is needed: I implemented this pattern = several months ago during the design team discussions when we were = considering this pattern, and the code is all online for people to = see. 

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

    On the AS side, the most = interesting code to this discussion is in the TransactionEndpoint = class:

    https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/= java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java

    Here, you=E2=80=99= ll see that on initial request, the server looks up the client to see if = it=E2=80=99s been registered, but after that, it makes sure that the = token and key are appropriate for the ongoing request. =46rom the client = side it=E2=80=99s even simpler. The client=E2=80=99s got a small service = function to manage the different signature methods that are implemented, = and all of them can take in an optional access token: 

    https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/= java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java

    The heavy lift is doing = the actual signing, and you need that in order to start the process = anyway. Managing the access token as an artifact to use at the API is = completely trivial since the client already needs to manage its own = state internally to do any of this. And note that all of this is changed = from how it was before: Previously, the XYZ Protocol had used a = =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the client = would use to continue the request. However, this simple model was = limiting, and the design team adopted XAuth=E2=80=99s model of = continuation being an API. In doing so, we made it like all of the other = APIs the client is going to call: in the initial state, it doesn=E2=80=99t= have any kind of access rights, it=E2=80=99s just calling. =46rom that = initial call forward, the AS just needs to know that the token and key = match what it expects. 

    In summary, my views are:
     - The access token pattern has a lot of benefits, = otherwise we wouldn=E2=80=99t have an entire OAuth ecosystem based on = it
     - Magic URIs have a lot of drawbacks which = are well understood; while they can be mitigated, they can also be = avoided
     - Continuation is an API, and = treating it like the other kinds of API the client would call makes = sense
     - Calling this by a special name, like = =E2=80=9Cgrant access token=E2=80=9D or =E2=80=9Ccontinuation access = token=E2=80=9D is fine, but it should function like any other access = token
     - The heavy lift for clients is on = protecting the message cryptographically, which they need to do = anyway

     =E2= =80=94 Justin


    On Dec = 15, 2020, at 7:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    The persistent = identifier is not a different issue, the current access token is = used to reference an existing = grant 

    It = may not be more difficult for a client to use an = access token at the AS / RS. But there is definitely an overhead on = the client to manage this separate access = token. 



    On Tue, 15 = Dec 2020 at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I think = we always said the access token was different, and handled as a bound = token.

    But it = doesn't mean it's more difficult for the client that already needs to be = able to handle tokens anyway (bearer or not, both cases could occur). = It's mostly consolidating the logic.

    You're anticipating a = lot of issues which have no specific reason to occur, such as "can't= be used with the token management APIs?". The management API is part of = the same general flow.
    Anticipating issues with rotation is useful, but there are = also many ways it can be hard to manage through a stateful approach too. = And fundamentally, having everything in a common model (both for the = internals of the AS and for the API calls) will help improve by a large = margin what is probably the weakest point in today's infrastructure. But = it's early to be definitive as to the downstream impact either = way.   

    As = for a persistent identifier instead of a continuation API, and generally = the end of your message, it's a totally unrelated issue to this PR, so I = suggest we don't discuss that here, but in a separate issue if = needed.

    Fabien

    On Tue, Dec = 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established that this is a different = access token, that requires different handling at the client. So keeping = it could cause more confusion?

    As an RC, I = will have to store the continue `uri` as although it could be static it = could also be dynamic. Why do I need to store an access token as = well. It brings me no benefit as an RC, in fact it brings more = complexity. As I will now need to manage multiple types of tokens with = different lifecycles:

    Continuation token 
      - can = only be used at the continue endpoint (the name of which is confusing as = I can use this endpoint to revoke a grant or get metadata on the = grant).
     - may be = rotated each time it is used, or may not be
     - provided in the `continue` section of the = response
     - must = be sender-constrained
     - can't = be used with the token management APIs?
     - can be = used to identify the grant when making subsequent grants

    Access token(s) to use at RS
      - can only be used at = the specified RS
      - may = be sender constrained
      - when = used at the RS, will not result in rotation

    =46rom my = perspective, most use-cases will require the RC to have a persistent = identifier for the grant. Why not bring this into the protocol and let = the AS provide this persistent identifier (through the form of the = continue uri). Using a rotating access token as a persistent identifier = doesn't seem like the right choice. 

    I see no = security benefit to having the continuation access token. It doesn't = matter if the continue uri leaks as it is useless without an = accompanying signature, i.e. any security benefit of having an access = token is already provided by having a signature.

    The only = benefits that I can see are:
     - If the = AS wants to be fully stateless, then you can encode more data in a token = than in a uri
     - If the = AS wants to have a static endpoint for CRUD operations on the = grant
     - To = allow the AS to identity a previous grant

    If we dropped = the access token for the continue endpoint and rather mandated a dynamic = uri this would make things conceptually easier to understand, easier for = the RC to implement, easier to debug and less chance of errors when = rotating tokens (i.e. race conditions could be quite likely if the AS = always rotates the token)

    One-off grant with no continuation or ongoing = management:
    RC sends = signature and metadata, no `continue` response provided, therefore no = grant management possible

    Grant with ongoing management
    RC sends signature and metadata, AS responds with a = continue uri that has these purposes:
     - can be = used by the RC to continue/update, read or revoke the grant
     - can be used by the RC when making a new = grant to identify the previous grant

    As an RC the = only permanent items I need to store are:
     - the continue uri associated with the = grant
     - any = access tokens I receive for the grant

    Dave

    On Tue, 15 = Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Torsten, 

    You're = right on both accounts. 
    - for the first = remark, it fits quite nicely the init request  / continuation = pattern 
    - for the second remark, it is a sort = of handle for the continuation request, which will eventually lead = to the issuance or refresh of standard access tokens 

    Having a = specific name is a possibility, I actually suggested that too at = some point. 

    Fabien

    On Tue, Dec = 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as = described in 3.1 and which is not a bearer token (that's what the "key" = : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token = at the continuation is a good idea otherwise the AS would need to be = able to parse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind = of resource. However, here are some observations I want to share with = you:
    - This resource is different as it will issue other access tokens (of = this kind) to be used in subsequent continuation requests. This requires = different handing on the client side.
    - This access token (if I understand correctly) is (or at least feels = like) a handle for the underlying grant. So it is kind of the super = access token to obtain other access tokens.

    I would consider using a different term to refer to this special access = token, grant token or grant handle for example, in order to prevent = confusion.

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question = seems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98= m not sure whether the continuation requests accepts any access token = issued to the RC or the particular access token returned in the = =E2=80=9Econtinue=E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com>:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very = good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that = was sort of in the back of my mind, it isn't a huge risk there. So I = actually agree with Dick there. Something doesn't sit right with me for = the unique URL solution, so I don't like it and came up with a = hypothetical that seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is = the way I'd like to go, because again, it's a mechanism I'd be = implementing anyway to talk to any 'normal' resource. The fact is there = is _something_ representing context that has to pass back and forth = here, whether that is an access token (which I feel like is more = flexible for extensions etc), a unique url, or even a cookie sent in the = cookie header. So just to re-iterate, I'm a +1 on this pull request, = speaking as a lazy developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but this = PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already = decided that wouldn't be how that would work. We have a client instance = that allows a more generic and flexible pattern (which BTW also allows = what you want)
    >>
    >> 2) instead of blame arguments of who's less = restful/HATEOAS/whatever that have the tenancy to flame conversations, I = suggest we speak in less abstract terms and ask ourselves what that = means in practice for devs. Stephen and several others (myself included) = have expressed that it wouldn't be harder to implement, it would even = simplify things quite a lot. If you disagree please send us a code = sample to really show that point by example, because that's really not = obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersonate = the client, and all bets are off." Are you seriously making this = argument? Because if you have a better proposal than using cryptographic = keys, I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digital = communications.
    >> 
    >> And more importantly you never responded to the issues of how = to avoid the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST = identify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in = this request as described in {{request-key}}. This field is REQUIRED. =
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    = >>
    >> The client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object.
    >> 
    >>
    >> If you don't have the access token, then how do you = differentiate between two requests from the same web application by two = different users? Is the web application supposed to have different = credentials for every request?
    >>
    >> The AS returns a URI for manipulating the request. I would = change the spec so that each request would have a unique URI. This is = the usually RESTful pattern that the resource (the grant request) has an = URI.
    >>
    >> 
    >> So in this case, the easy way out is to pass the access token = to the client, who then, as i stated before, treats the continue request = as a RS call (albeit a specialized version of the RS where the RS is the = AS) OR to use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. = (What would be the point of that attack, I don't know, I guess if = someone had the client credentials but not any subjects/resources they = could try to intercept the grant via continue... I just don't feel right = locking things down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the = client, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my = proposal is no different.
    >>
    >>
    >> 
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in = the body. The client is signing all the subsequent requests as well. The = "access token" is not needed by the client to prove it is authorized as = the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so it = does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the = client for subsequent calls, they can put it in the URL or some other = method. Putting it in the HTTP Authorization header is confusing because = it is NOT an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel the = need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS = as part of this request, it provides it's key in the body... (So no use = of the Authorization header)
    >> At this point that request, represented by the continue URL + = "Access Token", from my lazy developer standpoint, is a Resource = Endpoint and Access Token, and the AS is acting as a specialized RS in = this case.
    >> So my client posts to whatever URL with the 'access token' in = the authorization header, just like acting on any other resource I have = a token for. YES, I get a new token value to use every call, and there = is a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client.
    >> Personally I like that, because if I have an access_token, I = already think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I = wanted to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token" is not = the same as access tokens for an RS. The client gets a new "access = token" for each grant request, and for each API call to the AS, and the = client learns it can not make any more API calls for that specific = request when it does not get an "access token" back. This is a = completely different design pattern than calling an RS API with an = access token, and is a new design pattern for calling APIs. This adds = complexity to the client that it would not normally have, and I don't = think GNAP is the right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the = same thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical.
    >>
    >> The client is getting the "access token" from its API. It is = not using an "access_token" in other API calls to the AS.
    >> 
    >>
    >> Rotation of the access token and artifacts for ongoing = continuation responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87
    >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right = place to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me.
    >> 
    >>
    >>> 4) Clients that only want claims from the AS and no access = tokens will be required to support an API calling mechanism they would = not have to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make = with and without an access token is vanishingly small. The client has to = sign the initial request in some fashion, and it will sign the = continuation request in the same exact fashion, but now include an = access token in that request.
    >>
    >> Per my other point, there is no value to me in my = implementations of passing context back and forth between the client and = AS -- so it is extra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the = HTTP Authentication header is precluded from using it.
    >>
    >> 
    >>
    >> Clients making a request to an AS and not getting an access = token is a new design pattern. I think it has value and should be = included, but OAuth today shows us the immense value of getting access = tokens for calling APIs, and so we shouldn=E2=80=99t optimize away from = that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", there is = no mechanism for a client to delete the request, as the client is not = allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that = deleting a request does not seem like it is a "continue" operation.
    >> 
    >>
    >>>
    >>> 6) There is no standard identifier for the request. = Debugging and auditing are hampered by the client and AS having no = standard way to identifying a request. While one AS may provide a unique = URL for each grant request, another AS may use a persistent "access = token" to identify the grant request, and other ASs may issue a new = "access token" on each API call, providing no persistent identifier for = the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the = AS. How is interoperability harmed by different ASs having different = methods to identify their internal data elements? The client doesn=E2=80=99= t need any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was = referring to. How does a client developer identify the request when = communicating to the AS developer. Seems complicated.
    >> 
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    = >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    = >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.org
    >> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3D= AOvVaw0r39lH4qVOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub = Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL
    t: +44 (0)117 280 = 5120

    Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. = Moneyhub Financial Technology is = registered in England & Wales, company registration = number  06909772 .
    Moneyhub Financial Technology Limited 2019 =C2=A9

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

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

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub = Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL
    t: +44 (0)117 280 = 5120

    Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. = Moneyhub Financial Technology is = registered in England & Wales, company registration = number  06909772 .
    Moneyhub Financial Technology Limited 2019 =C2=A9

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

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

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



    = --Apple-Mail=_8EEB5960-D221-4BB6-95E6-71C2E75B495C-- From nobody Tue Dec 15 07:26:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB3D3A0E26 for ; Tue, 15 Dec 2020 07:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_40=-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, 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 oWMHyWMWdxny for ; Tue, 15 Dec 2020 07:26:04 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72AA3A0E22 for ; Tue, 15 Dec 2020 07:26:04 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id d9so20861700iob.6 for ; Tue, 15 Dec 2020 07:26:04 -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=vXJ+P/H42pDOPsWIdTKs1edNbR9NwNomCYcft/NYzx8=; b=fa4Y5UzxX3n4lGird7PZo+lkGXAlZALdBCMqZ4bbGlS65J0h0N/6K1AJJZ0p2Eeklz 3Tv6/6lkMstW/IZeIMFrZEc+PAy5Bw3+rXFJl2xl99+6O6V85hQ39Ze06hKhRcJNJiFX XOx6X5JzaKom5kEGsVpPUtB+OwFvBLRsdERgYbtMAk43iwquxIN4+BuPaiPg33JjEMoC /XA9H1EK4l4cRPFWM1KNqd1pygw9v6MJbBtuFm6YCgs97Labzpwgl58pwLDPAIecGmoL OY5Fz4EjYURU0nJMUalo+mg3/1a4T5lTGEmDMFsRTQDi/BHVkSd7GDUpEknhedgIRp/E XdzQ== 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=vXJ+P/H42pDOPsWIdTKs1edNbR9NwNomCYcft/NYzx8=; b=TgcQUjuhgCYtu7tXfT/0NNmIGBgkVP91Qd6ty9zoiAVOaXqVV7bdoU7vXEJrtszYLr ymgRWUyoqCwu9SVydb1lSmDFuecd7jvGWeY0rSX21o82C3rfcZlPI8KZuss3SuBuFXR+ We8eWeFB2/lydWx33c6B1prjBTRmDcMIhepPvJLAWVcfq4ehdxLi3Mpi479mAWM7nV3w hfotSfKxmfguR6Y8TxjUjtlLOIQrXv5ZBStoiDbUcKEDn0q739CYEiR/q0jRa/J+6cJL m4HPlUqpGM/J/Kql3tMLOW1zoxN1bhm/9UiwbPnc4YdPsRr/EQ3nI8YQS4hhsxQ53yRB pe5Q== X-Gm-Message-State: AOAM530j7tw3GPpbUx7hDexrUEoq9ou8GUPwRyxFO0gAqfswiWgo5oCV +diOi28YZx/R03LJ4q7WF01dQSjynyQlADnYSq170BSoLwkfIVht X-Google-Smtp-Source: ABdhPJxWvvK7g6zlnDf+HWr3z0mXQHqakyhVvBaW3rYMsIo0n0lEogxCGfmplojdtRH09MoOlzk6McboG7m9pJ1B8J0= X-Received: by 2002:a02:4b42:: with SMTP id q63mr8930275jaa.77.1608045955470; Tue, 15 Dec 2020 07:25:55 -0800 (PST) MIME-Version: 1.0 From: Fabien Imbault Date: Tue, 15 Dec 2020 16:25:41 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000001f16305b68260e9" Archived-At: Subject: [GNAP] Definition subject information 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, 15 Dec 2020 15:26:06 -0000 --00000000000001f16305b68260e9 Content-Type: text/plain; charset="UTF-8" Dear all, The terminology wiki has been updated with all the comments (and changes refer to the discussion on the mailing list). There remains the definition for "subject information" which I didn't cover in the previous batch of definitions. Current definition: 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. *Subject information* Definition: claim asserted locally by an AS about a person, organization or device Source: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP) Might require a definition for subject (i.e. person, organization or device), but it seems redundant with entity. Either we use subject elsewhere or we change to entity information. And for claim: a statement about a subject/entity. Fabien --00000000000001f16305b68260e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear all,=C2=A0

    The terminology wik= i has been updated with all the comments (and changes refer to the discussi= on on the mailing list).

    There remains the definit= ion for "subject information" which I didn't cover in the pre= vious batch of definitions.

    Current definition:=C2= =A0Information 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.=C2=A0=C2=A0

    Subject information
    Definition:=C2=A0claim=C2=A0asserted locally by an A= S about a person, organization or device
    https://tools.ietf.org/html/draft-ietf-= secevent-subject-identifiers-06 (unless we plan to use something specif= ic to GNAP)

    Might require a definition for subject= =C2=A0(i.e. person, organization or device), but it seems redundant with en= tity. Either we use subject elsewhere or we change to entity information.= =C2=A0
    And for claim:=C2=A0a statement about a subject/entity.

    Fabien

    --00000000000001f16305b68260e9-- From nobody Tue Dec 15 07:51:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3D03A11DB for ; Tue, 15 Dec 2020 07:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC2W5TGP-RSD for ; Tue, 15 Dec 2020 07:51:07 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DC03A11B7 for ; Tue, 15 Dec 2020 07:51:07 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id x16so28379459ejj.7 for ; Tue, 15 Dec 2020 07:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dGGB+wssWc3kqVO0cZDnmJGTVSwjiLxc8E63j+Zhpgw=; b=dY3f9UK4tM4Hl5ovPrf/OWXjqAH/bTusaqTgshGxdnS5eVQA4dYju5Chsg8Lzw2hdd rUsSEcDkLdpAWa4jWFa/n89owiEVkRAqwAIUymRdMTEYS3/K7AVKfWcl8v169DHDLsEQ YirgkyZ/VyKzJV8x52ysuFE5rwnaaggGjKZDI= 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=dGGB+wssWc3kqVO0cZDnmJGTVSwjiLxc8E63j+Zhpgw=; b=WIk+JSj9IErBOQrnCKmCVjdNc7/MRckrL4hudZB4i8irYtqS/PUt4Zu+ECmRhpQ0z+ yu/sVmWP7J8W+xL/ZsMscxmNsvhmQbC+LGynMQzVUMKy6LSKOAp9sqqBOI0a7Zp7zmk9 LdJV8eTH1lnbG1BDBauhmZz7ynVhkXgWJU5QoLOf8r0KwXo2G0RgH5Mp9erGzi4YYYC2 G8cbmI3goM6A7KsdDmqR7GXfykq5Ub/LpS8Ly33pZ0ZrxTC5sfg9HSHQ4MtM2+N3peVH r/3pIVibliciLOKvmcu8ttp9X+J+RtzQcFlWAPpLzv3ElZaThm3HuUCvmzKqfxYts99R pU4Q== X-Gm-Message-State: AOAM531ADrjvrzLUUgDJ6UI6MtjyNPrhPg+DnMnhwjS5ODwIfvFUHybj 4D+/0rFq5SCyiYMKAZMkES4ltdpnGjEYVe921Pye/YMcJfComkvzvT10Ubl1ksvmkwyDKJV1TS0 OUw384Nk9r261lFE= X-Google-Smtp-Source: ABdhPJxX+26jb/Gdwzltvgvzl+hwF6ZvIn6KuJcomW0KnvlWxPJFA5ILqXzOMu8LWPKZ1+sdMu29HJmkkZCWFJn94pw= X-Received: by 2002:a17:906:8594:: with SMTP id v20mr27058606ejx.470.1608047465194; Tue, 15 Dec 2020 07:51:05 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> In-Reply-To: <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> From: Dave Tonge Date: Tue, 15 Dec 2020 16:50:53 +0100 Message-ID: To: Justin Richer Cc: Fabien Imbault , Torsten Lodderstedt , txauth gnap , Steve Moore , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000f2085505b682b92a" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 15:51:13 -0000 --000000000000f2085505b682b92a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The access token pattern has a lot of benefits, otherwise we wouldn=E2=80= =99t have an entire OAuth ecosystem based on it *But what are the benefits in this particular use case?* The continuation API is not like any other API - it is integral to the AS. There are quite a few extensions to OAuth that use client authentication rather than access tokens. From a previous email the advantages I see are: - more data can be encoded in a token than in a uri (this seems more of an edge case) - it can be an identifier for the grant (I don't agree with this) Another question I have: *do we envisage granting access tokens to the RC that will allow it to manage multiple grants*? I also think there will be confusion with the signing being used for different things. Maybe it just needs to be called out in the spec that: Request 1: signature =3D client authentication Request 2+: signature =3D proof of possession for access token On Tue, 15 Dec 2020 at 15:33, Justin Richer wrote: > I agree with Fabien that the persistent identifier is a separate issue. > The current spec re-uses the access token for this artifact, but that=E2= =80=99s > potentially brittle and could be changed out for something else. There=E2= =80=99s an > issue asking for expanding on the use cases for this functionality (which > hasn=E2=80=99t been addressed by this PR): > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 > > A potentially-rotating URI would be just as brittle, and so having a > single codified identifier for this artifact would be useful, but it does > assume some things about the nature of the AS. Every other use the client > has to manage the ongoing request over time doesn=E2=80=99t need an expli= cit > identifier. Just like with OAuth-protected APIs, the server can determine > the context not just from the URI but from the rest of the request, > including the access token itself. This is both more common and more > powerful than a strict reading of REST designs. It also follows the HATEO= S > principles as the entire HTTP request is taken into account, including th= e > access token and signature portions. > > I=E2=80=99ll also point out that the rotation of these credentials is als= o filed > as a separate issue that=E2=80=99s not being addressed right now, so we c= an revisit > that discussion separately: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 > > As for the name, we could give it a different label. We have this same > pattern of issuing a resource-specific access token alongside a URL in th= e > Dynamic Registration specification, both in OAuth ( > https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( > https://openid.net/specs/openid-connect-registration-1_0.html#Registratio= nResponse). > Here it=E2=80=99s called the =E2=80=9Cregistration access token=E2=80=9D = =E2=80=94 but what=E2=80=99s important > there, as it is here, is that it=E2=80=99s not a different kind of artifa= ct that > the client now has to figure out how to use, it=E2=80=99s an access token= plain and > simple. In the OAuth world this is a bearer token, since that=E2=80=99s w= hat OAuth > 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2=80= =99s what we=E2=80=99re > looking to build on. This is also related to another future discussion > about responses tying an access token to a specific API that=E2=80=99s to= ld to the > client, as we could potentially re-use those components and concepts here > as well: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 > > And finally, no speculation on the complexity is needed: I implemented > this pattern several months ago during the design team discussions when w= e > were considering this pattern, and the code is all online for people to > see. > > https://github.com/bspk/oauth.xyz-java/ > > On the AS side, the most interesting code to this discussion is in the > TransactionEndpoint class: > > > https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bs= pk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java > > Here, you=E2=80=99ll see that on initial request, the server looks up the= client > to see if it=E2=80=99s been registered, but after that, it makes sure tha= t the > token and key are appropriate for the ongoing request. From the client si= de > it=E2=80=99s even simpler. The client=E2=80=99s got a small service funct= ion to manage the > different signature methods that are implemented, and all of them can tak= e > in an optional access token: > > > https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bs= pk/oauth/xyz/http/SigningRestTemplateService.java > > The heavy lift is doing the actual signing, and you need that in order to > start the process anyway. Managing the access token as an artifact to use > at the API is completely trivial since the client already needs to manage > its own state internally to do any of this. And note that all of this is > changed from how it was before: Previously, the XYZ Protocol had used a > =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the client w= ould use to > continue the request. However, this simple model was limiting, and the > design team adopted XAuth=E2=80=99s model of continuation being an API. I= n doing > so, we made it like all of the other APIs the client is going to call: in > the initial state, it doesn=E2=80=99t have any kind of access rights, it= =E2=80=99s just > calling. From that initial call forward, the AS just needs to know that t= he > token and key match what it expects. > > In summary, my views are: > - The access token pattern has a lot of benefits, otherwise we wouldn=E2= =80=99t > have an entire OAuth ecosystem based on it > - Magic URIs have a lot of drawbacks which are well understood; while > they can be mitigated, they can also be avoided > - Continuation is an API, and treating it like the other kinds of API th= e > client would call makes sense > - Calling this by a special name, like =E2=80=9Cgrant access token=E2=80= =9D or > =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should functi= on like any other > access token > - The heavy lift for clients is on protecting the message > cryptographically, which they need to do anyway > > =E2=80=94 Justin > > > On Dec 15, 2020, at 7:50 AM, Dave Tonge wrote: > > The persistent identifier is not a different issue, the current access > token is used to reference an existing grant > > > > It may not be more difficult for a client to *use* an access token at the > AS / RS. But there is definitely an overhead on the client to *manage* th= is > separate access token. > > > > On Tue, 15 Dec 2020 at 12:10, Fabien Imbault > wrote: > >> I think we always said the access token was different, and handled as a >> bound token. >> >> But it doesn't mean it's more difficult for the client that already need= s >> to be able to handle tokens anyway (bearer or not, both cases could occu= r). >> It's mostly consolidating the logic. >> >> You're anticipating a lot of issues which have no specific reason to >> occur, such as "can't be used with the token management APIs?". The >> management API is part of the same general flow. >> Anticipating issues with rotation is useful, but there are also many way= s >> it can be hard to manage through a stateful approach too. And >> fundamentally, having everything in a common model (both for the interna= ls >> of the AS and for the API calls) will help improve by a large margin wha= t >> is probably the weakest point in today's infrastructure. But it's early = to >> be definitive as to the downstream impact either way. >> >> As for a persistent identifier instead of a continuation API, and >> generally the end of your message, it's a totally unrelated issue to thi= s >> PR, so I suggest we don't discuss that here, but in a separate issue if >> needed. >> >> Fabien >> >> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >> wrote: >> >>> So we've established that this is a different access token, that >>> requires different handling at the client. So keeping it could cause mo= re >>> confusion? >>> >>> As an RC, I will have to store the continue `uri` as although it could >>> be static it could also be dynamic. Why do I need to store an access to= ken >>> as well. It brings me no benefit as an RC, in fact it brings more >>> complexity. As I will now need to manage multiple types of tokens with >>> different lifecycles: >>> >>> *Continuation token* >>> - can only be used at the continue endpoint (the name of which is >>> confusing as I can use this endpoint to revoke a grant or get metadata = on >>> the grant). >>> - may be rotated each time it is used, or may not be >>> - provided in the `continue` section of the response >>> - must be sender-constrained >>> - can't be used with the token management APIs? >>> - can be used to identify the grant when making subsequent grants >>> >>> *Access token(s) to use at RS* >>> - can only be used at the specified RS >>> - may be sender constrained >>> - when used at the RS, will not result in rotation >>> >>> From my perspective, most use-cases will require the RC to have a >>> persistent identifier for the grant. Why not bring this into the protoc= ol >>> and let the AS provide this persistent identifier (through the form of = the >>> continue uri). Using a rotating access token as a persistent identifier >>> doesn't seem like the right choice. >>> >>> I see no security benefit to having the continuation access token. It >>> doesn't matter if the continue uri leaks as it is useless without an >>> accompanying signature, i.e. any security benefit of having an access t= oken >>> is already provided by having a signature. >>> >>> The only benefits that I can see are: >>> - If the AS wants to be fully stateless, then you can encode more data >>> in a token than in a uri >>> - If the AS wants to have a static endpoint for CRUD operations on the >>> grant >>> - To allow the AS to identity a previous grant >>> >>> If we dropped the access token for the continue endpoint and rather >>> mandated a dynamic uri this would make things conceptually easier to >>> understand, easier for the RC to implement, easier to debug and less ch= ance >>> of errors when rotating tokens (i.e. race conditions could be quite lik= ely >>> if the AS always rotates the token) >>> >>> *One-off grant with no continuation or ongoing management:* >>> RC sends signature and metadata, no `continue` response provided, >>> therefore no grant management possible >>> >>> *Grant with ongoing management* >>> RC sends signature and metadata, AS responds with a continue uri that >>> has these purposes: >>> - can be used by the RC to continue/update, read or revoke the grant >>> - can be used by the RC when making a new grant to identify the >>> previous grant >>> >>> As an RC the only permanent items I need to store are: >>> - the continue uri associated with the grant >>> - any access tokens I receive for the grant >>> >>> Dave >>> >>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >>> wrote: >>> >>>> Hi Torsten, >>>> >>>> You're right on both accounts. >>>> - for the first remark, it fits quite nicely the init request / >>>> continuation pattern >>>> - for the second remark, it is a sort of handle for the >>>> continuation request, which will eventually lead to the issuance or re= fresh >>>> of standard access tokens >>>> >>>> Having a specific name is a possibility, I actually suggested that too >>>> at some point. >>>> >>>> Fabien >>>> >>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>>> Hi Fabien, >>>>> >>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>> fabien.imbault@gmail.com>: >>>>> > >>>>> > Hi, >>>>> > >>>>> > On the contrary your feedback is most welcome. >>>>> > >>>>> > It doesn't accept any token, it needs the particular token as >>>>> described in 3.1 and which is not a bearer token (that's what the "ke= y" : >>>>> true parameter is supposed to convey). >>>>> > >>>>> > Let us know if you need more clarifications. >>>>> >>>>> Thanks for the clarification. I think only accepting this kind of >>>>> token at the continuation is a good idea otherwise the AS would need = to be >>>>> able to parse and understand all sorts of access tokens. >>>>> >>>>> Conceptually, I like the idea to treat the continuation as another >>>>> kind of resource. However, here are some observations I want to share= with >>>>> you: >>>>> - This resource is different as it will issue other access tokens (of >>>>> this kind) to be used in subsequent continuation requests. This requi= res >>>>> different handing on the client side. >>>>> - This access token (if I understand correctly) is (or at least feels >>>>> like) a handle for the underlying grant. So it is kind of the super a= ccess >>>>> token to obtain other access tokens. >>>>> >>>>> I would consider using a different term to refer to this special >>>>> access token, grant token or grant handle for example, in order to pr= event >>>>> confusion. >>>>> >>>>> best regards, >>>>> Torsten. >>>>> >>>>> >>>>> > >>>>> > Best >>>>> > Fabien >>>>> > >>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>> > Hi all, >>>>> > >>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me question= seems >>>>> naive. >>>>> > >>>>> > After having skimmed through the current draft and the PR, I=E2=80= =98m not >>>>> sure whether the continuation requests accepts any access token issue= d to >>>>> the RC or the particular access token returned in the =E2=80=9Econtin= ue=E2=80=9C element in >>>>> section 3.1.. >>>>> > >>>>> > Can you please shed some light on this? >>>>> > >>>>> > kind regards, >>>>> > Torsten. >>>>> > >>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>> fabien.imbault@gmail.com>: >>>>> >> >>>>> >> =EF=BB=BF >>>>> >> You're completely right. Allowing the dev to be lazy is a very goo= d >>>>> thing in general, because it's what we know will work :-) >>>>> >> >>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >>>>> =C3=A9crit : >>>>> >> Hi Fabien, >>>>> >> >>>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>>> sort of in the back of my mind, it isn't a huge risk there. So I actu= ally >>>>> agree with Dick there. Something doesn't sit right with me for the un= ique >>>>> URL solution, so I don't like it and came up with a hypothetical that= seems >>>>> like it could be a down side. >>>>> >> >>>>> >> I still think the access token model with the signed request is th= e >>>>> way I'd like to go, because again, it's a mechanism I'd be implementi= ng >>>>> anyway to talk to any 'normal' resource. The fact is there is _someth= ing_ >>>>> representing context that has to pass back and forth here, whether th= at is >>>>> an access token (which I feel like is more flexible for extensions et= c), a >>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy develop= er ;) >>>>> >> -steve >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >> Again speaking in my own name here. >>>>> >> >>>>> >> Dick, we know you'd prefer to have a different design, but this PR >>>>> shouldn't be about that. >>>>> >> >>>>> >> Back on your 3 items : >>>>> >> >>>>> >> 1) yes we could make pre-register mandatory, but we already decide= d >>>>> that wouldn't be how that would work. We have a client instance that = allows >>>>> a more generic and flexible pattern (which BTW also allows what you w= ant) >>>>> >> >>>>> >> 2) instead of blame arguments of who's less >>>>> restful/HATEOAS/whatever that have the tenancy to flame conversations= , I >>>>> suggest we speak in less abstract terms and ask ourselves what that m= eans >>>>> in practice for devs. Stephen and several others (myself included) ha= ve >>>>> expressed that it wouldn't be harder to implement, it would even simp= lify >>>>> things quite a lot. If you disagree please send us a code sample to r= eally >>>>> show that point by example, because that's really not obvious. >>>>> >> >>>>> >> 3) "If someone has the client credentials, they can impersonate th= e >>>>> client, and all bets are off." Are you seriously making this argument= ? >>>>> Because if you have a better proposal than using cryptographic keys, = I'm >>>>> all hears. You make it look like there's a problem, while in reality = we're >>>>> only relying on the basic assumption of all modern digital communicat= ions. >>>>> >> >>>>> >> And more importantly you never responded to the issues of how to >>>>> avoid the security pitfalls of what you proposed. >>>>> >> >>>>> >> Fabien >>>>> >> >>>>> >> >>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>>>> =C3=A9crit : >>>>> >> >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>> wrote: >>>>> >> But from the spec: >>>>> >> " >>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>> identify itself by including the client field of the request... >>>>> >> ... >>>>> >> key (object / string) : The public key of the RC to be used in thi= s >>>>> request as described in {{request-key}}. This field is REQUIRED. >>>>> >> ... >>>>> >> " >>>>> >> So on the initial request, the key will be there. >>>>> >> >>>>> >> The client field can be an object or a string. If the client is >>>>> pre-registered, then a string could be provided instead of an object. >>>>> >> >>>>> >> >>>>> >> If you don't have the access token, then how do you differentiate >>>>> between two requests from the same web application by two different u= sers? >>>>> Is the web application supposed to have different credentials for eve= ry >>>>> request? >>>>> >> >>>>> >> The AS returns a URI for manipulating the request. I would change >>>>> the spec so that each request would have a unique URI. This is the us= ually >>>>> RESTful pattern that the resource (the grant request) has an URI. >>>>> >> >>>>> >> >>>>> >> So in this case, the easy way out is to pass the access token to >>>>> the client, who then, as i stated before, treats the continue request= as a >>>>> RS call (albeit a specialized version of the RS where the RS is the A= S) OR >>>>> to use the unique URL, >>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>> (What would be the point of that attack, I don't know, I guess if som= eone >>>>> had the client credentials but not any subjects/resources they could = try to >>>>> intercept the grant via continue... I just don't feel right locking t= hings >>>>> down to unique URLs that way.) >>>>> >> >>>>> >> If someone has the client credentials, they can impersonate the >>>>> client, and all bets are off. >>>>> >> >>>>> >> LOTS of RS servers return a resource specific URL -- my proposal i= s >>>>> no different. >>>>> >> >>>>> >> >>>>> >> >>>>> >> -steve >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>> wrote: >>>>> >> Hi Stephen >>>>> >> >>>>> >> The client is signing the first request. The key *might* be in the >>>>> body. The client is signing all the subsequent requests as well. The >>>>> "access token" is not needed by the client to prove it is authorized = as the >>>>> client is proving it is the same client again. >>>>> >> >>>>> >> In other words, I don't see the need for an access token, so it >>>>> does not need to be put in a URL or an auth header. >>>>> >> >>>>> >> If a developer really, really wants to hand context back to the >>>>> client for subsequent calls, they can put it in the URL or some other >>>>> method. Putting it in the HTTP Authorization header is confusing beca= use it >>>>> is NOT an access token -- it is the context of the request. >>>>> >> >>>>> >> =E1=90=A7 >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>> wrote: >>>>> >> Even though I've only been lightly following things, I feel the >>>>> need to voice my preference as a developer since I will probably some= day >>>>> have to either write a RC or RS... >>>>> >> >>>>> >> The way I see it is the RC makes the initial request to the AS as >>>>> part of this request, it provides it's key in the body... (So no use = of the >>>>> Authorization header) >>>>> >> At this point that request, represented by the continue URL + >>>>> "Access Token", from my lazy developer standpoint, is a Resource Endp= oint >>>>> and Access Token, and the AS is acting as a specialized RS in this ca= se. >>>>> >> So my client posts to whatever URL with the 'access token' in the >>>>> authorization header, just like acting on any other resource I have a= token >>>>> for. YES, I get a new token value to use every call, and there is a >>>>> decision point of "Do I have another continue, or do I have a real to= ken >>>>> for the resource..." But the mechanism is the same to me in the clien= t. >>>>> >> Personally I like that, because if I have an access_token, I >>>>> already think "Put it in the auth header." >>>>> >> >>>>> >> So my vote would be +1 for the pull request at this time. >>>>> >> -steve >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>> wrote: >>>>> >> inline ... >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>> wrote: >>>>> >> Others had already responded to this previous thread, but I wanted >>>>> to add a couple points to clarify some things. >>>>> >> >>>>> >>> 3) What the client has to do with the "access token" is not the >>>>> same as access tokens for an RS. The client gets a new "access token"= for >>>>> each grant request, and for each API call to the AS, and the client l= earns >>>>> it can not make any more API calls for that specific request when it = does >>>>> not get an "access token" back. This is a completely different design >>>>> pattern than calling an RS API with an access token, and is a new des= ign >>>>> pattern for calling APIs. This adds complexity to the client that it = would >>>>> not normally have, and I don't think GNAP is the right place to start= a new >>>>> design pattern. >>>>> >>> >>>>> >> >>>>> >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole >>>>> point of the design is that the client would be doing the same thing = with >>>>> the access token at the AS that it does with the RS by re-using the a= ccess >>>>> token structure. Can you please describe what the differences are, ap= art >>>>> from the rotation? Presentation of the token and signing of the messa= ge are >>>>> identical. >>>>> >> >>>>> >> The client is getting the "access token" from its API. It is not >>>>> using an "access_token" in other API calls to the AS. >>>>> >> >>>>> >> >>>>> >> Rotation of the access token and artifacts for ongoing continuatio= n >>>>> responses is a separate issue to be discussed: >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>> >> >>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have >>>>> new designs =E2=80=94 not that this is one. >>>>> >> >>>>> >> You are proposing a new way for an API to provide context for >>>>> subsequent API calls. Looks out of scope to me. >>>>> >> >>>>> >> >>>>> >>> 4) Clients that only want claims from the AS and no access tokens >>>>> will be required to support an API calling mechanism they would not h= ave to >>>>> support otherwise. >>>>> >> >>>>> >> Correct, but the delta between the calls a client would make with >>>>> and without an access token is vanishingly small. The client has to s= ign >>>>> the initial request in some fashion, and it will sign the continuatio= n >>>>> request in the same exact fashion, but now include an access token in= that >>>>> request. >>>>> >> >>>>> >> Per my other point, there is no value to me in my implementations >>>>> of passing context back and forth between the client and AS -- so it = is >>>>> extra work providing no value. >>>>> >> >>>>> >> Also, any client authentication mechanism that wants to use the >>>>> HTTP Authentication header is precluded from using it. >>>>> >> >>>>> >> >>>>> >> >>>>> >> Clients making a request to an AS and not getting an access token >>>>> is a new design pattern. I think it has value and should be included,= but >>>>> OAuth today shows us the immense value of getting access tokens for c= alling >>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>> >> >>>>> >>> >>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>> mechanism for a client to delete the request, as the client is not al= lowed >>>>> to make a call without an "access token". >>>>> >> >>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>> is telling this client instance that it can=E2=80=99t do anything els= e with this >>>>> ongoing request. If the AS wants to allow the client to manage it, it= will >>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fie= ld. >>>>> >> >>>>> >> There is nuance in that intention. A related concern is that >>>>> deleting a request does not seem like it is a "continue" operation. >>>>> >> >>>>> >> >>>>> >>> >>>>> >>> 6) There is no standard identifier for the request. Debugging and >>>>> auditing are hampered by the client and AS having no standard way to >>>>> identifying a request. While one AS may provide a unique URL for each= grant >>>>> request, another AS may use a persistent "access token" to identify t= he >>>>> grant request, and other ASs may issue a new "access token" on each A= PI >>>>> call, providing no persistent identifier for the request. >>>>> >> >>>>> >> Debugging and auditing this kind of thing are functions of the AS. >>>>> How is interoperability harmed by different ASs having different meth= ods to >>>>> identify their internal data elements? The client doesn=E2=80=99t nee= d any >>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the = next steps for >>>>> continuing the negotiation. >>>>> >> >>>>> >> Debugging between the client and the AS was what I was referring >>>>> to. How does a client developer identify the request when communicati= ng to >>>>> the AS developer. Seems complicated. >>>>> >> >>>>> >> =E1=90=A7 >>>>> >> -- >>>>> >> TXAuth mailing list >>>>> >> TXAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>> >> =E1=90=A7 >>>>> >> -- >>>>> >> TXAuth mailing list >>>>> >> TXAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>> >> -- >>>>> >> TXAuth mailing list >>>>> >> TXAuth@ietf.org >>>>> >> >>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/= txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0I= QPJJYtSpI >>>>> >>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >>> -- >>> Dave Tonge >>> CTO >>> [image: Moneyhub Enterprise] >>> >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>> 6FL >>> t: +44 (0)117 280 5120 >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at *https://register.fca.org.u= k/ >>> *. Moneyhub Financial Technology is >>> registered in England & Wales, company registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS= 1 >>> 6EA. >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000f2085505b682b92a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    >=C2=A0The access token pattern has a lot of benefits, otherwise we wouldn= =E2=80=99t have an entire OAuth ecosystem based on it

    But what are the benefits=C2=A0in this particular use= case? The continuation API is not like any other API - it is integral = to the AS. There are quite a few extensions to OAuth that use client authen= tication rather than access tokens. From a previous email the advantages I = see are:
    =C2=A0- more data can be encoded= in a token than in a uri (this seems more of an edge case)
    =C2=A0- it can be an identifier for the grant (I don'= ;t agree with this)

    Another question I have: do we envisage granting acce= ss tokens to the RC that will allow it to manage multiple grants?=C2=A0= =C2=A0

    I also think there will be confusion with the signing being used for d= ifferent things. Maybe it just needs to be called out in the spec that:
    =

    R= equest 1: signature =3D client authentication
    Request 2+: signature =3D proof of possession for access token








    On Tue, 15 Dec 2020 at 15:33, Ju= stin Richer <jriche= r@mit.edu> wrote:
    I agree with Fabien that the persistent identifier is a sep= arate issue. The current spec re-uses the access token for this artifact, b= ut that=E2=80=99s potentially brittle and could be changed out for somethin= g else. There=E2=80=99s an issue asking for expanding on the use cases for = this functionality (which hasn=E2=80=99t been addressed by this PR):

    A potentially-rotating URI would be j= ust as brittle, and so having a single codified identifier for this artifac= t would be useful, but it does assume some things about the nature of the A= S. Every other use the client has to manage the ongoing request over time d= oesn=E2=80=99t need an explicit identifier. Just like with OAuth-protected = APIs, the server can determine the context not just from the URI but from t= he rest of the request, including the access token itself. This is both mor= e common and more powerful than a strict reading of REST designs. It also f= ollows the HATEOS principles as the entire HTTP request is taken into accou= nt, including the access token and signature portions.=C2=A0

    =
    I=E2=80=99ll also point out that the rotation of these credentia= ls is also filed as a separate issue that=E2=80=99s not being addressed rig= ht now, so we can revisit that discussion separately:

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87<= /a>

    As for the name, we could give it a different = label. We have this same pattern of issuing a resource-specific access toke= n alongside a URL in the Dynamic Registration specification, both in OAuth = (https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect (https://openid.net/specs/openid-connect= -registration-1_0.html#RegistrationResponse). Here it=E2=80=99s called = the =E2=80=9Cregistration access token=E2=80=9D =E2=80=94 but what=E2=80=99= s important there, as it is here, is that it=E2=80=99s not a different kind= of artifact that the client now has to figure out how to use, it=E2=80=99s= an access token plain and simple. In the OAuth world this is a bearer toke= n, since that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll = be a bound token, as that=E2=80=99s what we=E2=80=99re looking to build on.= This is also related to another future discussion about responses tying an= access token to a specific API that=E2=80=99s told to the client, as we co= uld potentially re-use those components and concepts here as well:


    And finally, no speculation= on the complexity is needed: I implemented this pattern several months ago= during the design team discussions when we were considering this pattern, = and the code is all online for people to see.=C2=A0

    htt= ps://github.com/bspk/oauth.xyz-java/

    On the AS= side, the most interesting code to this discussion is in the TransactionEn= dpoint class:


    Here, you=E2=80= =99ll see that on initial request, the server looks up the client to see if= it=E2=80=99s been registered, but after that, it makes sure that the token= and key are appropriate for the ongoing request. From the client side it= =E2=80=99s even simpler. The client=E2=80=99s got a small service function = to manage the different signature methods that are implemented, and all of = them can take in an optional access token:=C2=A0

    <= a href=3D"https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/ja= va/io/bspk/oauth/xyz/http/SigningRestTemplateService.java" target=3D"_blank= ">https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bs= pk/oauth/xyz/http/SigningRestTemplateService.java

    <= div>The heavy lift is doing the actual signing, and you need that in order = to start the process anyway. Managing the access token as an artifact to us= e at the API is completely trivial since the client already needs to manage= its own state internally to do any of this. And note that all of this is c= hanged from how it was before: Previously, the XYZ Protocol had used a =E2= =80=9Ctransaction handle=E2=80=9D returned by the AS that the client would = use to continue the request. However, this simple model was limiting, and t= he design team adopted XAuth=E2=80=99s model of continuation being an API. = In doing so, we made it like all of the other APIs the client is going to c= all: in the initial state, it doesn=E2=80=99t have any kind of access right= s, it=E2=80=99s just calling. From that initial call forward, the AS just n= eeds to know that the token and key match what it expects.=C2=A0
    =
    In summary, my views are:
    =C2=A0- The access token= pattern has a lot of benefits, otherwise we wouldn=E2=80=99t have an entir= e OAuth ecosystem based on it
    =C2=A0- Magic URIs have a lot of dr= awbacks which are well understood; while they can be mitigated, they can al= so be avoided
    =C2=A0- Continuation is an API, and treating it lik= e the other kinds of API the client would call makes sense
    =C2=A0= - Calling this by a special name, like =E2=80=9Cgrant access token=E2=80=9D= or =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should func= tion like any other access token
    =C2=A0- The heavy lift for clien= ts is on protecting the message cryptographically, which they need to do an= yway

    =C2=A0=E2=80=94 Justin

    On Dec 15, 2020, at 7:50 AM, Dave Tonge <= ;dave.tonge@mo= neyhub.com> wrote:

    The pe= rsistent identifier=C2=A0is not a different issue, the current access token= is used to reference an existing grant=C2= =A0

    It may not be more difficult for= a client to use an access token at the AS / RS. But there=C2=A0is d= efinitely an overhead on the client to manage=C2=A0this separate acc= ess token.=C2=A0


    On Tue, 1= 5 Dec 2020 at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I think= we always said the access token was different, and handled as a bound toke= n.

    But it doesn't mean it's more difficult for t= he client that already needs to be able to handle tokens anyway (bearer or = not, both cases could occur). It's mostly consolidating the logic.

    You're anticipating a lot of issues which hav= e no specific reason to occur, such as "can't be used with the token manageme= nt APIs?". The management API is part of the same general flow.=
    = Anticipating issues with rotation is useful, but there are also many ways i= t can be hard to manage through a stateful approach too. And fundamentally,= having everything in a common model (both for the internals of the AS and = for the API calls) will help improve by a large margin what is probably the= weakest point in today's infrastructure. But it's early to be defi= nitive as to the downstream impact either way.=C2=A0 =C2=A0

    <= /span>
    As for a persistent identifier instead of a continuation API, and gen= erally the end of your message, it's a totally unrelated issue to this = PR, so I suggest we don't discuss that here, but in a separate issue if= needed.

    Fabien

    On Tue, Dec 15, = 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we= 've established that this is a different access token, that requires di= fferent handling at the client. So keeping it could cause more confusion?

    As an RC, I will have to store the co= ntinue `uri` as although it could be static it could also be dynamic. Why d= o I need to store an access token as well.=C2=A0It brings me no benefit as = an RC, in fact it brings more complexity. As I will now need to manage mult= iple types of tokens with different lifecycles:

    =
    Continuation token=C2=A0
    =C2=A0 - can o= nly be used at the continue endpoint (the name of which is confusing as I c= an use this endpoint to revoke a grant or get metadata on the grant).
    =
    =C2=A0- may be rotated each time it is used, or may not be
    =C2=A0- provided in the `continue` section of the response
    =C2=A0- must be sender-constrained
    =C2=A0- c= an't be used with the token management APIs?
    =C2=A0- c= an be used to identify the grant when making subsequent grants

    Access token(s) to use at RS
    =C2=A0=C2=A0- can only be used at the specified RS
    =C2=A0 - may be sender constrained
    =C2=A0 - when used= at the RS, will not result in rotation

    From my perspective, most use-cases will require the RC to have a persi= stent identifier for the grant. Why not bring this into the protocol and le= t the AS provide this persistent identifier (through the form of the contin= ue uri). Using a rotating access token as a persistent identifier doesn'= ;t seem like the right choice.=C2=A0


    The only benefits that I can see are:
    =C2=A0- If the AS= wants to be fully stateless, then you can encode more data in a token than= in a uri
    =C2=A0- If the AS wants to have a static endpoin= t for CRUD operations on the grant
    =C2=A0- To allow the A= S to identity a previous grant

    If we= dropped the access token for the continue endpoint and rather mandated a d= ynamic uri this would make things conceptually easier to understand, easier= for the RC to implement, easier to debug and less chance of errors when ro= tating tokens (i.e. race conditions could be quite likely if the AS always = rotates the token)

    One-off grant = with no continuation or ongoing management:
    RC sends s= ignature and metadata, no `continue` response provided, therefore no grant = management possible

    Grant with on= going management
    RC sends signature and metadata, AS r= esponds with a continue uri that has these purposes:
    =C2= =A0- can be used by the RC to continue/update, read or revoke the grant
    =C2=A0- can be used by the RC when making a new grant to iden= tify the previous grant

    As an RC the= only permanent items I need to store are:
    =C2=A0- the con= tinue uri associated with the grant
    =C2=A0- any access tok= ens I receive for the grant

    Dave

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrot= e:
    Hi Torsten,=C2=A0

    You're right on both accounts.= =C2=A0
    - for the first remark, it fits quite nicely the init requ= est=C2=A0 / continuation pattern=C2=A0
    - for the second remark, i= t is a sort of handle for the continuation=C2=A0request, which will eventua= lly lead to the issuance or refresh of standard access tokens=C2=A0

    Having a specific=C2=A0name is a possibility, I actually = suggested that too at some point.=C2=A0

    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net>= wrote:
    Hi Fabie= n,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

    Moneyhub Enterprise is a trading style of Moneyhub Fin= ancial Technology Limited which is authorised and regulated by the Financia= l Conduct Authority ("FCA"). Moneyhub Financial Technology is ent= ered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/<= /span>. Moneyhub Financial Technology is registered in England & Wa= les, company registration number 06909772. Moneyhub Financial Technology Li= mited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friar= y, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is su= bject to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthoris= ed and unlawful. Whilst reasonable efforts are made to ensure that any atta= chments are virus-free, it is the recipient's sole responsibility to sc= an all attachments for viruses. All calls and emails to and from this compa= ny may be monitored and recorded for legitimate purposes relating to this c= ompany's business. Any opinions expressed in this email (or in any atta= chments) are those of the author and do not necessarily represent the opini= ons of Moneyhub Financial Technology Limited or of any other group company.=




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

    Moneyhub Enterprise is a trading style of Moneyhub Fin= ancial Technology Limited which is authorised and regulated by the Financia= l Conduct Authority ("FCA"). Moneyhub Financial Technology is ent= ered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/<= /span>. Moneyhub Financial Technology is registered in England & Wa= les, company registration number 06909772. Moneyhub Financial Technology Li= mited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friar= y, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is su= bject to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthoris= ed and unlawful. Whilst reasonable efforts are made to ensure that any atta= chments are virus-free, it is the recipient's sole responsibility to sc= an all attachments for viruses. All calls and emails to and from this compa= ny may be monitored and recorded for legitimate purposes relating to this c= ompany's business. Any opinions expressed in this email (or in any atta= chments) are those of the author and do not necessarily represent the opini= ons of Moneyhub Financial Technology Limited or of any other group company.=



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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --000000000000f2085505b682b92a-- From nobody Tue Dec 15 08:30:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7BF3A1222 for ; Tue, 15 Dec 2020 08:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnGi2M8xJVfM for ; Tue, 15 Dec 2020 08:30:38 -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 B21613A121C for ; Tue, 15 Dec 2020 08:30:37 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BFGUXf4027671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Dec 2020 11:30:34 -0500 From: Justin Richer Message-Id: <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F9F82488-9290-483E-A6A3-12DAE28E8FFD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 15 Dec 2020 11:30:33 -0500 In-Reply-To: Cc: Fabien Imbault , Torsten Lodderstedt , txauth gnap , Steve Moore , Dick Hardt To: Dave Tonge References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 16:30:46 -0000 --Apple-Mail=_F9F82488-9290-483E-A6A3-12DAE28E8FFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 15, 2020, at 10:50 AM, Dave Tonge = wrote: >=20 > > The access token pattern has a lot of benefits, otherwise we = wouldn=E2=80=99t have an entire OAuth ecosystem based on it >=20 > But what are the benefits in this particular use case? The = continuation API is not like any other API - it is integral to the AS. = There are quite a few extensions to OAuth that use client authentication = rather than access tokens. Yes, and the propagation of that has lead to a mess in the OAuth world. = You=E2=80=99ve got re-definitions of client authentications at all = different endpoints, they=E2=80=99re technically allowed to vary between = endpoints (though I don=E2=80=99t know of it happening in practice, that = feels like a downgrade attack waiting to happen to someone). Then = there=E2=80=99s the fact that all the newest security mechanisms we have = =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 don=E2=80=99t rely on client = authentication at all to achieve security. All of these work without the = client having credentials previously known to the AS, and we already = know that GNAP is going to need to live in this more dynamic world. We = need to think beyond what OAuth 2 has done in the past, and especially = from our perceptions and assumptions of the models that drive OAuth = 2=E2=80=99s decisions, lest we repeat its mistakes.=20 Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2=80=9D= as a point. In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the = server side, but in OAuth 2 we split that into the RS concept. Even = though in practice, a lot of RS=E2=80=99s are still integrated to the AS = in some fashion because it=E2=80=99s a single service, OAuth 2 is clear = about what=E2=80=99s expected to be known by each component. For the AS = as currently defined in GNAP, I=E2=80=99m seeing three distinct = functions. As per the Terminology discussion, we don=E2=80=99t have = explicit names for these yet: - starting a request; this is an endpoint to kick things off; it needs = to be able to look up the rights asked for by the client (if it knows = the client at all ahead of time) and make initial decisions about needed = interaction and follow up - continuing a request; this is an API that needs to know the context = of the request itself, including which key it=E2=80=99s bound to; this = is separate from any identity of the client and possibly the user, but = an AS implementation that has access to those elements can use them - interacting with the user; this is front-facing and in OAuth today is = already deployed as a separate service in some places, we should embrace = that at the very least (but doing so formally is a separate issue) Why separate these in this way? There is immense power in having a = single consistent way to start the process. The =E2=80=9Ccontinuation = API=E2=80=9D gives us an HTTP-defined mechanism for managing a request = over time, including the simple case of returning information from the = front channel, but people have already raised the question of non-HTTP = and self-hosted AS=E2=80=99s, which would probably want a different kind = of continuation API to communicate to the AS. The same thing with = separating out the interaction: there are going to be a lot of different = ways to handle interaction out there, and not all of them will be = =E2=80=9Cintegral=E2=80=9D to the AS in the way that a simple = implementation might do. We=E2=80=99re defining a protocol based = strongly on HTTP and JSON, but we should structure it in such a way that = it can be extended and translated elsewhere in a clear way. This all raises the question: if we can rely on a unique URL for = redirect-based interaction, why not here? The simple reason is that a = URL is the :only: mechanism we have in the front channel for passing = information, and we need to warn implementors against including = sensitive information in it, and we need to protect it with additional = items. We have access to more than just URLs when we=E2=80=99re dealing = with the continuation API, and we ought to make use of all of our tools = in ways that are consistent and make sense. > =46rom a previous email the advantages I see are: > - more data can be encoded in a token than in a uri (this seems more = of an edge case) > - it can be an identifier for the grant (I don't agree with this) It allows the parts above to live separately, even if they don=E2=80=99t = HAVE to. And it simplifies what we=E2=80=99re asking the client to do by = making it consistent with other parts of the ecosystem. The AS offering = an API doesn=E2=80=99t :have: to be different, and OpenID Connect showed = us, with the UserInfo Endpoint, that that=E2=80=99s very much the case = in practice.=20 Having my client code do very similar things in slightly different ways = is not simpler. >=20 > Another question I have: do we envisage granting access tokens to the = RC that will allow it to manage multiple grants? =20 I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t = been brought up as a use case to date.=20 >=20 > I also think there will be confusion with the signing being used for = different things. Maybe it just needs to be called out in the spec that: >=20 > Request 1: signature =3D client authentication > Request 2+: signature =3D proof of possession for access token >=20 That=E2=80=99s more or less the intent of what=E2=80=99s in the = specification right now, and why all the signature methods, which are = used for both client auth and token possession, are all together in = section 8 and not separated by use. (With the caveat: it=E2=80=99s only = client authentication in the first request if the AS knows about the = client instance ahead of time, which isn=E2=80=99t always going to be = true.) That all can likely be made clearer, as is always the case with = spec text. But you can use the signature methods with and without access = tokens, and it only gets used without in an initial call where you = don=E2=80=99t :have: an access token to present. Separating the different kinds of =E2=80=9Cclient authentication" out in = OAuth is the source of some real confusion. Like right now, what happens = if you try to combine a client assertion, signed request objects for = PAR, and DPoP proofs, all in a single request? All of these are optional = and all of them =E2=80=9Cdo client authentication=E2=80=9D in some = arguable fashion. I=E2=80=99ve worked on several systems and implemented = these things, and their interplay is really confusing to manage and can = go sideways really fast. And that=E2=80=99s just the work for a single = endpoint, this gets repeated for introspection, revocation, CIBA, = device, and on. At the end of the day I=E2=80=99m in favor of giving the client = developers a very clear set of directions on what they need to do and = how they need to access things, and treating the continuation as a = token-bound API is, to me, the clearest pattern we can offer for this = piece. =E2=80=94 Justin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, 15 Dec 2020 at 15:33, Justin Richer > wrote: > I agree with Fabien that the persistent identifier is a separate = issue. The current spec re-uses the access token for this artifact, but = that=E2=80=99s potentially brittle and could be changed out for = something else. There=E2=80=99s an issue asking for expanding on the use = cases for this functionality (which hasn=E2=80=99t been addressed by = this PR): >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = >=20 > A potentially-rotating URI would be just as brittle, and so having a = single codified identifier for this artifact would be useful, but it = does assume some things about the nature of the AS. Every other use the = client has to manage the ongoing request over time doesn=E2=80=99t need = an explicit identifier. Just like with OAuth-protected APIs, the server = can determine the context not just from the URI but from the rest of the = request, including the access token itself. This is both more common and = more powerful than a strict reading of REST designs. It also follows the = HATEOS principles as the entire HTTP request is taken into account, = including the access token and signature portions.=20 >=20 > I=E2=80=99ll also point out that the rotation of these credentials is = also filed as a separate issue that=E2=80=99s not being addressed right = now, so we can revisit that discussion separately: >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = >=20 > As for the name, we could give it a different label. We have this same = pattern of issuing a resource-specific access token alongside a URL in = the Dynamic Registration specification, both in OAuth = (https://tools.ietf.org/html/rfc7592#section-3 = ) and OpenID Connect = (https://openid.net/specs/openid-connect-registration-1_0.html#Registratio= nResponse = ). Here it=E2=80=99s called the =E2=80=9Cregistration access = token=E2=80=9D =E2=80=94 but what=E2=80=99s important there, as it is = here, is that it=E2=80=99s not a different kind of artifact that the = client now has to figure out how to use, it=E2=80=99s an access token = plain and simple. In the OAuth world this is a bearer token, since = that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll be a = bound token, as that=E2=80=99s what we=E2=80=99re looking to build on. = This is also related to another future discussion about responses tying = an access token to a specific API that=E2=80=99s told to the client, as = we could potentially re-use those components and concepts here as well: >=20 > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 = >=20 > And finally, no speculation on the complexity is needed: I implemented = this pattern several months ago during the design team discussions when = we were considering this pattern, and the code is all online for people = to see.=20 >=20 > https://github.com/bspk/oauth.xyz-java/ = >=20 > On the AS side, the most interesting code to this discussion is in the = TransactionEndpoint class: >=20 > = https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bsp= k/oauth/xyz/authserver/endpoint/TransactionEndpoint.java = >=20 > Here, you=E2=80=99ll see that on initial request, the server looks up = the client to see if it=E2=80=99s been registered, but after that, it = makes sure that the token and key are appropriate for the ongoing = request. =46rom the client side it=E2=80=99s even simpler. The = client=E2=80=99s got a small service function to manage the different = signature methods that are implemented, and all of them can take in an = optional access token:=20 >=20 > = https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bsp= k/oauth/xyz/http/SigningRestTemplateService.java = >=20 > The heavy lift is doing the actual signing, and you need that in order = to start the process anyway. Managing the access token as an artifact to = use at the API is completely trivial since the client already needs to = manage its own state internally to do any of this. And note that all of = this is changed from how it was before: Previously, the XYZ Protocol had = used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the = client would use to continue the request. However, this simple model was = limiting, and the design team adopted XAuth=E2=80=99s model of = continuation being an API. In doing so, we made it like all of the other = APIs the client is going to call: in the initial state, it doesn=E2=80=99t= have any kind of access rights, it=E2=80=99s just calling. =46rom that = initial call forward, the AS just needs to know that the token and key = match what it expects.=20 >=20 > In summary, my views are: > - The access token pattern has a lot of benefits, otherwise we = wouldn=E2=80=99t have an entire OAuth ecosystem based on it > - Magic URIs have a lot of drawbacks which are well understood; while = they can be mitigated, they can also be avoided > - Continuation is an API, and treating it like the other kinds of API = the client would call makes sense > - Calling this by a special name, like =E2=80=9Cgrant access token=E2=80= =9D or =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it = should function like any other access token > - The heavy lift for clients is on protecting the message = cryptographically, which they need to do anyway >=20 > =E2=80=94 Justin >=20 >=20 >> On Dec 15, 2020, at 7:50 AM, Dave Tonge > wrote: >>=20 >> The persistent identifier is not a different issue, the current = access token is used to reference an existing grant = =20 >>=20 >> It may not be more difficult for a client to use an access token at = the AS / RS. But there is definitely an overhead on the client to manage = this separate access token.=20 >>=20 >>=20 >>=20 >> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault = > wrote: >> I think we always said the access token was different, and handled as = a bound token. >>=20 >> But it doesn't mean it's more difficult for the client that already = needs to be able to handle tokens anyway (bearer or not, both cases = could occur). It's mostly consolidating the logic. >>=20 >> You're anticipating a lot of issues which have no specific reason to = occur, such as "can't be used with the token management APIs?". The = management API is part of the same general flow. >> Anticipating issues with rotation is useful, but there are also many = ways it can be hard to manage through a stateful approach too. And = fundamentally, having everything in a common model (both for the = internals of the AS and for the API calls) will help improve by a large = margin what is probably the weakest point in today's infrastructure. But = it's early to be definitive as to the downstream impact either way. =20 >>=20 >> As for a persistent identifier instead of a continuation API, and = generally the end of your message, it's a totally unrelated issue to = this PR, so I suggest we don't discuss that here, but in a separate = issue if needed. >>=20 >> Fabien >>=20 >> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge > wrote: >> So we've established that this is a different access token, that = requires different handling at the client. So keeping it could cause = more confusion? >>=20 >> As an RC, I will have to store the continue `uri` as although it = could be static it could also be dynamic. Why do I need to store an = access token as well. It brings me no benefit as an RC, in fact it = brings more complexity. As I will now need to manage multiple types of = tokens with different lifecycles: >>=20 >> Continuation token=20 >> - can only be used at the continue endpoint (the name of which is = confusing as I can use this endpoint to revoke a grant or get metadata = on the grant). >> - may be rotated each time it is used, or may not be >> - provided in the `continue` section of the response >> - must be sender-constrained >> - can't be used with the token management APIs? >> - can be used to identify the grant when making subsequent grants >>=20 >> Access token(s) to use at RS >> - can only be used at the specified RS >> - may be sender constrained >> - when used at the RS, will not result in rotation >>=20 >> =46rom my perspective, most use-cases will require the RC to have a = persistent identifier for the grant. Why not bring this into the = protocol and let the AS provide this persistent identifier (through the = form of the continue uri). Using a rotating access token as a persistent = identifier doesn't seem like the right choice.=20 >>=20 >> I see no security benefit to having the continuation access token. It = doesn't matter if the continue uri leaks as it is useless without an = accompanying signature, i.e. any security benefit of having an access = token is already provided by having a signature. >>=20 >> The only benefits that I can see are: >> - If the AS wants to be fully stateless, then you can encode more = data in a token than in a uri >> - If the AS wants to have a static endpoint for CRUD operations on = the grant >> - To allow the AS to identity a previous grant >>=20 >> If we dropped the access token for the continue endpoint and rather = mandated a dynamic uri this would make things conceptually easier to = understand, easier for the RC to implement, easier to debug and less = chance of errors when rotating tokens (i.e. race conditions could be = quite likely if the AS always rotates the token) >>=20 >> One-off grant with no continuation or ongoing management: >> RC sends signature and metadata, no `continue` response provided, = therefore no grant management possible >>=20 >> Grant with ongoing management >> RC sends signature and metadata, AS responds with a continue uri that = has these purposes: >> - can be used by the RC to continue/update, read or revoke the grant >> - can be used by the RC when making a new grant to identify the = previous grant >>=20 >> As an RC the only permanent items I need to store are: >> - the continue uri associated with the grant >> - any access tokens I receive for the grant >>=20 >> Dave >>=20 >> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault = > wrote: >> Hi Torsten,=20 >>=20 >> You're right on both accounts.=20 >> - for the first remark, it fits quite nicely the init request / = continuation pattern=20 >> - for the second remark, it is a sort of handle for the continuation = request, which will eventually lead to the issuance or refresh of = standard access tokens=20 >>=20 >> Having a specific name is a possibility, I actually suggested that = too at some point.=20 >>=20 >> Fabien >>=20 >> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt = > wrote: >> Hi Fabien,=20 >>=20 >> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault = >: >> >=20 >> > Hi, >> >=20 >> > On the contrary your feedback is most welcome.=20 >> >=20 >> > It doesn't accept any token, it needs the particular token as = described in 3.1 and which is not a bearer token (that's what the "key" = : true parameter is supposed to convey).=20 >> >=20 >> > Let us know if you need more clarifications.=20 >>=20 >> Thanks for the clarification. I think only accepting this kind of = token at the continuation is a good idea otherwise the AS would need to = be able to parse and understand all sorts of access tokens. >>=20 >> Conceptually, I like the idea to treat the continuation as another = kind of resource. However, here are some observations I want to share = with you:=20 >> - This resource is different as it will issue other access tokens (of = this kind) to be used in subsequent continuation requests. This requires = different handing on the client side. >> - This access token (if I understand correctly) is (or at least feels = like) a handle for the underlying grant. So it is kind of the super = access token to obtain other access tokens.=20 >>=20 >> I would consider using a different term to refer to this special = access token, grant token or grant handle for example, in order to = prevent confusion.=20 >>=20 >> best regards, >> Torsten.=20 >>=20 >>=20 >> >=20 >> > Best >> > Fabien=20 >> >=20 >> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt = > a =C3=A9crit = : >> > Hi all, >> >=20 >> > I didn=E2=80=99t follow GNAP closely so bear with me if me question = seems naive. >> >=20 >> > After having skimmed through the current draft and the PR, I=E2=80=98= m not sure whether the continuation requests accepts any access token = issued to the RC or the particular access token returned in the = =E2=80=9Econtinue=E2=80=9C element in section 3.1.. >> >=20 >> > Can you please shed some light on this? >> >=20 >> > kind regards, >> > Torsten. >> >=20 >> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault = >: >> >>=20 >> >> =EF=BB=BF >> >> You're completely right. Allowing the dev to be lazy is a very = good thing in general, because it's what we know will work :-)=20 >> >>=20 >> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore = > a =C3=A9crit : >> >> Hi Fabien, >> >>=20 >> >> For #3) Even after I typed out the hypothetical attack, that was = sort of in the back of my mind, it isn't a huge risk there. So I = actually agree with Dick there. Something doesn't sit right with me for = the unique URL solution, so I don't like it and came up with a = hypothetical that seems like it could be a down side. >> >>=20 >> >> I still think the access token model with the signed request is = the way I'd like to go, because again, it's a mechanism I'd be = implementing anyway to talk to any 'normal' resource. The fact is there = is _something_ representing context that has to pass back and forth = here, whether that is an access token (which I feel like is more = flexible for extensions etc), a unique url, or even a cookie sent in the = cookie header. So just to re-iterate, I'm a +1 on this pull request, = speaking as a lazy developer ;) >> >> -steve >> >>=20 >> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault = > wrote: >> >> Again speaking in my own name here.=20 >> >>=20 >> >> Dick, we know you'd prefer to have a different design, but this PR = shouldn't be about that.=20 >> >>=20 >> >> Back on your 3 items : >> >>=20 >> >> 1) yes we could make pre-register mandatory, but we already = decided that wouldn't be how that would work. We have a client instance = that allows a more generic and flexible pattern (which BTW also allows = what you want)=20 >> >>=20 >> >> 2) instead of blame arguments of who's less = restful/HATEOAS/whatever that have the tenancy to flame conversations, I = suggest we speak in less abstract terms and ask ourselves what that = means in practice for devs. Stephen and several others (myself included) = have expressed that it wouldn't be harder to implement, it would even = simplify things quite a lot. If you disagree please send us a code = sample to really show that point by example, because that's really not = obvious.=20 >> >>=20 >> >> 3) "If someone has the client credentials, they can impersonate = the client, and all bets are off." Are you seriously making this = argument? Because if you have a better proposal than using cryptographic = keys, I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digital = communications.=20 >> >> =20 >> >> And more importantly you never responded to the issues of how to = avoid the security pitfalls of what you proposed.=20 >> >>=20 >> >> Fabien=20 >> >>=20 >> >>=20 >> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = > a =C3=A9crit : >> >>=20 >> >>=20 >> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore > wrote: >> >> But from the spec: >> >> " >> >> When sending a non-continuation request to the AS, the RC MUST = identify itself by including the client field of the request... >> >> ... >> >> key (object / string) : The public key of the RC to be used in = this request as described in {{request-key}}. This field is REQUIRED.=20 >> >> ... >> >> " >> >> So on the initial request, the key will be there.=20 >> >>=20 >> >> The client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object. >> >> =20 >> >>=20 >> >> If you don't have the access token, then how do you differentiate = between two requests from the same web application by two different = users? Is the web application supposed to have different credentials for = every request? >> >>=20 >> >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the = usually RESTful pattern that the resource (the grant request) has an = URI. >> >>=20 >> >> =20 >> >> So in this case, the easy way out is to pass the access token to = the client, who then, as i stated before, treats the continue request as = a RS call (albeit a specialized version of the RS where the RS is the = AS) OR to use the unique URL,=20 >> >> but that seems open to a brute force attack by a malicious RC. = (What would be the point of that attack, I don't know, I guess if = someone had the client credentials but not any subjects/resources they = could try to intercept the grant via continue... I just don't feel right = locking things down to unique URLs that way.) >> >>=20 >> >> If someone has the client credentials, they can impersonate the = client, and all bets are off. >> >>=20 >> >> LOTS of RS servers return a resource specific URL -- my proposal = is no different. >> >>=20 >> >>=20 >> >> =20 >> >> -steve >> >>=20 >> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt > wrote: >> >> Hi Stephen >> >>=20 >> >> The client is signing the first request. The key *might* be in the = body. The client is signing all the subsequent requests as well. The = "access token" is not needed by the client to prove it is authorized as = the client is proving it is the same client again. >> >>=20 >> >> In other words, I don't see the need for an access token, so it = does not need to be put in a URL or an auth header. >> >>=20 >> >> If a developer really, really wants to hand context back to the = client for subsequent calls, they can put it in the URL or some other = method. Putting it in the HTTP Authorization header is confusing because = it is NOT an access token -- it is the context of the request. >> >>=20 >> >> =E1=90=A7 >> >>=20 >> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore > wrote: >> >> Even though I've only been lightly following things, I feel the = need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...=20 >> >>=20 >> >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of = the Authorization header) >> >> At this point that request, represented by the continue URL + = "Access Token", from my lazy developer standpoint, is a Resource = Endpoint and Access Token, and the AS is acting as a specialized RS in = this case. >> >> So my client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a = token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client. >> >> Personally I like that, because if I have an access_token, I = already think "Put it in the auth header."=20 >> >>=20 >> >> So my vote would be +1 for the pull request at this time. >> >> -steve >> >>=20 >> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt > wrote: >> >> inline ...=20 >> >>=20 >> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer > wrote: >> >> Others had already responded to this previous thread, but I wanted = to add a couple points to clarify some things. >> >>=20 >> >>> 3) What the client has to do with the "access token" is not the = same as access tokens for an RS. The client gets a new "access token" = for each grant request, and for each API call to the AS, and the client = learns it can not make any more API calls for that specific request when = it does not get an "access token" back. This is a completely different = design pattern than calling an RS API with an access token, and is a new = design pattern for calling APIs. This adds complexity to the client that = it would not normally have, and I don't think GNAP is the right place to = start a new design pattern. >> >>>=20 >> >>=20 >> >> I=E2=80=99m not sure what you mean by these being different =E2=80=94= the whole point of the design is that the client would be doing the = same thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical. >> >>=20 >> >> The client is getting the "access token" from its API. It is not = using an "access_token" in other API calls to the AS. >> >> =20 >> >>=20 >> >> Rotation of the access token and artifacts for ongoing = continuation responses is a separate issue to be discussed: = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = >> >>=20 >> >> And for what it=E2=80=99s worth, GNAP is absolutely the right = place to have new designs =E2=80=94 not that this is one. >> >>=20 >> >> You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me. >> >> =20 >> >>=20 >> >>> 4) Clients that only want claims from the AS and no access tokens = will be required to support an API calling mechanism they would not have = to support otherwise.=20 >> >>=20 >> >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign = the initial request in some fashion, and it will sign the continuation = request in the same exact fashion, but now include an access token in = that request.=20 >> >>=20 >> >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is = extra work providing no value. >> >>=20 >> >> Also, any client authentication mechanism that wants to use the = HTTP Authentication header is precluded from using it. >> >>=20 >> >> =20 >> >>=20 >> >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, = but OAuth today shows us the immense value of getting access tokens for = calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern. >> >>=20 >> >>>=20 >> >>> 5) If the AS does not provide an "access token", there is no = mechanism for a client to delete the request, as the client is not = allowed to make a call without an "access token". >> >>=20 >> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D= field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. >> >>=20 >> >> There is nuance in that intention. A related concern is that = deleting a request does not seem like it is a "continue" operation. >> >> =20 >> >>=20 >> >>>=20 >> >>> 6) There is no standard identifier for the request. Debugging and = auditing are hampered by the client and AS having no standard way to = identifying a request. While one AS may provide a unique URL for each = grant request, another AS may use a persistent "access token" to = identify the grant request, and other ASs may issue a new "access token" = on each API call, providing no persistent identifier for the request. >> >>=20 >> >> Debugging and auditing this kind of thing are functions of the AS. = How is interoperability harmed by different ASs having different methods = to identify their internal data elements? The client doesn=E2=80=99t = need any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps for continuing the negotiation. >> >>=20 >> >> Debugging between the client and the AS was what I was referring = to. How does a client developer identify the request when communicating = to the AS developer. Seems complicated. >> >> =20 >> >> =E1=90=A7 >> >> --=20 >> >> TXAuth mailing list >> >> TXAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth = >> >> =E1=90=A7 >> >> --=20 >> >> TXAuth mailing list >> >> TXAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth = >> >> --=20 >> >> TXAuth mailing list >> >> TXAuth@ietf.org >> >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJ= YtSpI = >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >> --=20 >> Dave Tonge >> CTO >> = >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, = BS1 6FL >> t: +44 (0)117 280 5120 >>=20 >> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >>=20 >> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>=20 >> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >>=20 >> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>=20 >>=20 >>=20 >>=20 >> --=20 >> Dave Tonge >> CTO >> = >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, = BS1 6FL >> t: +44 (0)117 280 5120 >>=20 >> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >>=20 >> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>=20 >> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >>=20 >> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>=20 >>=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Dave Tonge > CTO > = > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL > t: +44 (0)117 280 5120 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 --Apple-Mail=_F9F82488-9290-483E-A6A3-12DAE28E8FFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 15, 2020, at 10:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    > The access = token pattern has a lot of benefits, otherwise we wouldn=E2=80=99t have = an entire OAuth ecosystem based on it

    But what are the benefits in this particular use = case? The continuation API is not like any other API - it is = integral to the AS. There are quite a few extensions to OAuth that use = client authentication rather than access = tokens.

    Yes, = and the propagation of that has lead to a mess in the OAuth world. = You=E2=80=99ve got re-definitions of client authentications at all = different endpoints, they=E2=80=99re technically allowed to vary between = endpoints (though I don=E2=80=99t know of it happening in practice, that = feels like a downgrade attack waiting to happen to someone). Then = there=E2=80=99s the fact that all the newest security mechanisms we have = =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 don=E2=80=99t rely on client = authentication at all to achieve security. All of these work without the = client having credentials previously known to the AS, and we already = know that GNAP is going to need to live in this more dynamic world. We = need to think beyond what OAuth 2 has done in the past, and especially = from our perceptions and assumptions of the models that drive OAuth = 2=E2=80=99s decisions, lest we repeat its mistakes. 

    Also, I want to challenge this idea of =E2=80=9Cinte= gral to the AS=E2=80=9D as a point. In OAuth 1, the API was = =E2=80=9Cintegral=E2=80=9D to the server side, but in OAuth 2 we split = that into the RS concept. Even though in practice, a lot of RS=E2=80=99s = are still integrated to the AS in some fashion because it=E2=80=99s a = single service, OAuth 2 is clear about what=E2=80=99s expected to be = known by each component. For the AS as currently defined in GNAP, I=E2=80=99= m seeing three distinct functions. As per the Terminology discussion, we = don=E2=80=99t have explicit names for these yet:

     - starting a request; this is an endpoint to = kick things off; it needs to be able to look up the rights asked for by = the client (if it knows the client at all ahead of time) and make = initial decisions about needed interaction and follow up
     - = continuing a request; this is an API that needs to know the context of = the request itself, including which key it=E2=80=99s bound to; this is = separate from any identity of the client and possibly the user, but an = AS implementation that has access to those elements can use = them
     - interacting with the user; this is front-facing = and in OAuth today is already deployed as a separate service in some = places, we should embrace that at the very least (but doing so formally = is a separate issue)

    Why separate = these in this way? There is immense power in having a single consistent = way to start the process. The =E2=80=9Ccontinuation API=E2=80=9D gives = us an HTTP-defined mechanism for managing a request over time, including = the simple case of returning information from the front channel, but = people have already raised the question of non-HTTP and self-hosted = AS=E2=80=99s, which would probably want a different kind of continuation = API to communicate to the AS. The same thing with separating out the = interaction: there are going to be a lot of different ways to handle = interaction out there, and not all of them will be =E2=80=9Cintegral=E2=80= =9D to the AS in the way that a simple implementation might do. We=E2=80=99= re defining a protocol based strongly on HTTP and JSON, but we should = structure it in such a way that it can be extended and translated = elsewhere in a clear way.

    This all raises the question: = if we can rely on a unique URL for redirect-based interaction, why not = here? The simple reason is that a URL is the :only: mechanism we have in = the front channel for passing information, and we need to warn = implementors against including sensitive information in it, and we need = to protect it with additional items. We have access to more than just = URLs when we=E2=80=99re dealing with the continuation API, and we ought = to make use of all of our tools in ways that are consistent and make = sense.

    =46rom a previous email the advantages I see = are:
     - more data can be encoded = in a token than in a uri (this seems more of an edge case)
     - it can be an identifier for the grant (I = don't agree with this)

    It allows the parts above to live separately, even = if they don=E2=80=99t HAVE to. And it simplifies what we=E2=80=99re = asking the client to do by making it consistent with other parts of the = ecosystem. The AS offering an API doesn=E2=80=99t :have: to be = different, and OpenID Connect showed us, with the UserInfo Endpoint, = that that=E2=80=99s very much the case in practice. 

    Having my client code do very similar things in = slightly different ways is not simpler.


    Another question I have: do we = envisage granting access tokens to the RC that will allow it to manage = multiple grants?  

    I don=E2=80=99t see that happening, personally, = and it hasn=E2=80=99t been brought up as a use case to = date. 


    I also think there will be = confusion with the signing being used for different things. Maybe it = just needs to be called out in the spec that:

    Request 1: signature =3D client = authentication
    Request 2+: signature =3D= proof of possession for access token


    That=E2=80=99s more or less the intent of what=E2=80= =99s in the specification right now, and why all the signature methods, = which are used for both client auth and token possession, are all = together in section 8 and not separated by use.  (With the caveat: = it=E2=80=99s only client authentication in the first request if the AS = knows about the client instance ahead of time, which isn=E2=80=99t = always going to be true.) That all can likely be made clearer, as is = always the case with spec text. But you can use the signature methods = with and without access tokens, and it only gets used without in an = initial call where you don=E2=80=99t :have: an access token to = present.

    Separating the different = kinds of =E2=80=9Cclient authentication" out in OAuth is the source of = some real confusion. Like right now, what happens if you try to combine = a client assertion, signed request objects for PAR, and DPoP proofs, all = in a single request? All of these are optional and all of them =E2=80=9Cdo= client authentication=E2=80=9D in some arguable fashion. I=E2=80=99ve = worked on several systems and implemented these things, and their = interplay is really confusing to manage and can go sideways really fast. = And that=E2=80=99s just the work for a single endpoint, this gets = repeated for introspection, revocation, CIBA, device, and = on.

    At the end of the day I=E2=80=99m = in favor of giving the client developers a very clear set of directions = on what they need to do and how they need to access things, and treating = the continuation as a token-bound API is, to me, the clearest pattern we = can offer for this piece.

     =E2=80= =94 Justin









    On Tue, 15 = Dec 2020 at 15:33, Justin Richer <jricher@mit.edu> wrote:
    I agree with Fabien = that the persistent identifier is a separate issue. The current spec = re-uses the access token for this artifact, but that=E2=80=99s = potentially brittle and could be changed out for something else. = There=E2=80=99s an issue asking for expanding on the use cases for this = functionality (which hasn=E2=80=99t been addressed by this PR):

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

    A = potentially-rotating URI would be just as brittle, and so having a = single codified identifier for this artifact would be useful, but it = does assume some things about the nature of the AS. Every other use the = client has to manage the ongoing request over time doesn=E2=80=99t need = an explicit identifier. Just like with OAuth-protected APIs, the server = can determine the context not just from the URI but from the rest of the = request, including the access token itself. This is both more common and = more powerful than a strict reading of REST designs. It also follows the = HATEOS principles as the entire HTTP request is taken into account, = including the access token and signature portions. 

    I=E2=80=99ll also point = out that the rotation of these credentials is also filed as a separate = issue that=E2=80=99s not being addressed right now, so we can revisit = that discussion separately:

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

    As for the = name, we could give it a different label. We have this same pattern of = issuing a resource-specific access token alongside a URL in the Dynamic = Registration specification, both in OAuth (https://tools.ietf.org/html/rfc7592#section-3) and OpenID = Connect (https://openid.net/specs/openid-connect-registration-1_0.html#R= egistrationResponse). Here it=E2=80=99s called the =E2=80=9Cregistrati= on access token=E2=80=9D =E2=80=94 but what=E2=80=99s important there, = as it is here, is that it=E2=80=99s not a different kind of artifact = that the client now has to figure out how to use, it=E2=80=99s an access = token plain and simple. In the OAuth world this is a bearer token, since = that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll be a = bound token, as that=E2=80=99s what we=E2=80=99re looking to build on. = This is also related to another future discussion about responses tying = an access token to a specific API that=E2=80=99s told to the client, as = we could potentially re-use those components and concepts here as = well:

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

    And finally, = no speculation on the complexity is needed: I implemented this pattern = several months ago during the design team discussions when we were = considering this pattern, and the code is all online for people to = see. 

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

    On the AS side, the most = interesting code to this discussion is in the TransactionEndpoint = class:

    https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/= java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java

    Here, you=E2=80=99= ll see that on initial request, the server looks up the client to see if = it=E2=80=99s been registered, but after that, it makes sure that the = token and key are appropriate for the ongoing request. =46rom the client = side it=E2=80=99s even simpler. The client=E2=80=99s got a small service = function to manage the different signature methods that are implemented, = and all of them can take in an optional access token: 

    https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/= java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java

    The heavy lift is doing = the actual signing, and you need that in order to start the process = anyway. Managing the access token as an artifact to use at the API is = completely trivial since the client already needs to manage its own = state internally to do any of this. And note that all of this is changed = from how it was before: Previously, the XYZ Protocol had used a = =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the client = would use to continue the request. However, this simple model was = limiting, and the design team adopted XAuth=E2=80=99s model of = continuation being an API. In doing so, we made it like all of the other = APIs the client is going to call: in the initial state, it doesn=E2=80=99t= have any kind of access rights, it=E2=80=99s just calling. =46rom that = initial call forward, the AS just needs to know that the token and key = match what it expects. 

    In summary, my views are:
     - The access token pattern has a lot of benefits, = otherwise we wouldn=E2=80=99t have an entire OAuth ecosystem based on = it
     - Magic URIs have a lot of drawbacks which = are well understood; while they can be mitigated, they can also be = avoided
     - Continuation is an API, and = treating it like the other kinds of API the client would call makes = sense
     - Calling this by a special name, like = =E2=80=9Cgrant access token=E2=80=9D or =E2=80=9Ccontinuation access = token=E2=80=9D is fine, but it should function like any other access = token
     - The heavy lift for clients is on = protecting the message cryptographically, which they need to do = anyway

     =E2= =80=94 Justin


    On Dec = 15, 2020, at 7:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    The persistent = identifier is not a different issue, the current access token is = used to reference an existing = grant 

    It may not be = more difficult for a client to use an access token at = the AS / RS. But there is definitely an overhead on the client to = manage this separate access = token. 



    On Tue, 15 Dec 2020 at 12:10, Fabien = Imbault <fabien.imbault@gmail.com> wrote:
    I think = we always said the access token was different, and handled as a bound = token.

    But it = doesn't mean it's more difficult for the client that already needs to be = able to handle tokens anyway (bearer or not, both cases could occur). = It's mostly consolidating the logic.

    You're anticipating a = lot of issues which have no specific reason to occur, such as "can't= be used with the token management APIs?". The management API is part of = the same general flow.
    Anticipating issues with rotation is useful, but there are = also many ways it can be hard to manage through a stateful approach too. = And fundamentally, having everything in a common model (both for the = internals of the AS and for the API calls) will help improve by a large = margin what is probably the weakest point in today's infrastructure. But = it's early to be definitive as to the downstream impact either = way.   

    As = for a persistent identifier instead of a continuation API, and generally = the end of your message, it's a totally unrelated issue to this PR, so I = suggest we don't discuss that here, but in a separate issue if = needed.

    Fabien

    On Tue, Dec = 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established that this is a different = access token, that requires different handling at the client. So keeping = it could cause more confusion?

    As an RC, I = will have to store the continue `uri` as although it could be static it = could also be dynamic. Why do I need to store an access token as = well. It brings me no benefit as an RC, in fact it brings more = complexity. As I will now need to manage multiple types of tokens with = different lifecycles:

    Continuation token 
      - can = only be used at the continue endpoint (the name of which is confusing as = I can use this endpoint to revoke a grant or get metadata on the = grant).
     - may be = rotated each time it is used, or may not be
     - provided in the `continue` section of the = response
     - must = be sender-constrained
     - can't = be used with the token management APIs?
     - can be = used to identify the grant when making subsequent grants

    Access token(s) to use at RS
      - can only be used at = the specified RS
      - may = be sender constrained
      - when = used at the RS, will not result in rotation

    =46rom my = perspective, most use-cases will require the RC to have a persistent = identifier for the grant. Why not bring this into the protocol and let = the AS provide this persistent identifier (through the form of the = continue uri). Using a rotating access token as a persistent identifier = doesn't seem like the right choice. 

    I see no = security benefit to having the continuation access token. It doesn't = matter if the continue uri leaks as it is useless without an = accompanying signature, i.e. any security benefit of having an access = token is already provided by having a signature.

    The only = benefits that I can see are:
     - If the = AS wants to be fully stateless, then you can encode more data in a token = than in a uri
     - If the = AS wants to have a static endpoint for CRUD operations on the = grant
     - To = allow the AS to identity a previous grant

    If we dropped = the access token for the continue endpoint and rather mandated a dynamic = uri this would make things conceptually easier to understand, easier for = the RC to implement, easier to debug and less chance of errors when = rotating tokens (i.e. race conditions could be quite likely if the AS = always rotates the token)

    One-off grant with no continuation or ongoing = management:
    RC sends = signature and metadata, no `continue` response provided, therefore no = grant management possible

    Grant with ongoing management
    RC sends signature and metadata, AS responds with a = continue uri that has these purposes:
     - can be = used by the RC to continue/update, read or revoke the grant
     - can be used by the RC when making a new = grant to identify the previous grant

    As an RC the = only permanent items I need to store are:
     - the continue uri associated with the = grant
     - any = access tokens I receive for the grant

    Dave

    On Tue, 15 = Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi = Torsten, 

    You're = right on both accounts. 
    - for the first = remark, it fits quite nicely the init request  / continuation = pattern 
    - for the second remark, it is a sort = of handle for the continuation request, which will eventually lead = to the issuance or refresh of standard access tokens 

    Having a = specific name is a possibility, I actually suggested that too at = some point. 

    Fabien

    On Tue, Dec = 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as = described in 3.1 and which is not a bearer token (that's what the "key" = : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token = at the continuation is a good idea otherwise the AS would need to be = able to parse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind = of resource. However, here are some observations I want to share with = you:
    - This resource is different as it will issue other access tokens (of = this kind) to be used in subsequent continuation requests. This requires = different handing on the client side.
    - This access token (if I understand correctly) is (or at least feels = like) a handle for the underlying grant. So it is kind of the super = access token to obtain other access tokens.

    I would consider using a different term to refer to this special access = token, grant token or grant handle for example, in order to prevent = confusion.

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question = seems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98= m not sure whether the continuation requests accepts any access token = issued to the RC or the particular access token returned in the = =E2=80=9Econtinue=E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com>:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very = good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that = was sort of in the back of my mind, it isn't a huge risk there. So I = actually agree with Dick there. Something doesn't sit right with me for = the unique URL solution, so I don't like it and came up with a = hypothetical that seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is = the way I'd like to go, because again, it's a mechanism I'd be = implementing anyway to talk to any 'normal' resource. The fact is there = is _something_ representing context that has to pass back and forth = here, whether that is an access token (which I feel like is more = flexible for extensions etc), a unique url, or even a cookie sent in the = cookie header. So just to re-iterate, I'm a +1 on this pull request, = speaking as a lazy developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but this = PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already = decided that wouldn't be how that would work. We have a client instance = that allows a more generic and flexible pattern (which BTW also allows = what you want)
    >>
    >> 2) instead of blame arguments of who's less = restful/HATEOAS/whatever that have the tenancy to flame conversations, I = suggest we speak in less abstract terms and ask ourselves what that = means in practice for devs. Stephen and several others (myself included) = have expressed that it wouldn't be harder to implement, it would even = simplify things quite a lot. If you disagree please send us a code = sample to really show that point by example, because that's really not = obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersonate = the client, and all bets are off." Are you seriously making this = argument? Because if you have a better proposal than using cryptographic = keys, I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digital = communications.
    >> 
    >> And more importantly you never responded to the issues of how = to avoid the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST = identify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in = this request as described in {{request-key}}. This field is REQUIRED. =
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    = >>
    >> The client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object.
    >> 
    >>
    >> If you don't have the access token, then how do you = differentiate between two requests from the same web application by two = different users? Is the web application supposed to have different = credentials for every request?
    >>
    >> The AS returns a URI for manipulating the request. I would = change the spec so that each request would have a unique URI. This is = the usually RESTful pattern that the resource (the grant request) has an = URI.
    >>
    >> 
    >> So in this case, the easy way out is to pass the access token = to the client, who then, as i stated before, treats the continue request = as a RS call (albeit a specialized version of the RS where the RS is the = AS) OR to use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. = (What would be the point of that attack, I don't know, I guess if = someone had the client credentials but not any subjects/resources they = could try to intercept the grant via continue... I just don't feel right = locking things down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the = client, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my = proposal is no different.
    >>
    >>
    >> 
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in = the body. The client is signing all the subsequent requests as well. The = "access token" is not needed by the client to prove it is authorized as = the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so it = does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the = client for subsequent calls, they can put it in the URL or some other = method. Putting it in the HTTP Authorization header is confusing because = it is NOT an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel the = need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS = as part of this request, it provides it's key in the body... (So no use = of the Authorization header)
    >> At this point that request, represented by the continue URL + = "Access Token", from my lazy developer standpoint, is a Resource = Endpoint and Access Token, and the AS is acting as a specialized RS in = this case.
    >> So my client posts to whatever URL with the 'access token' in = the authorization header, just like acting on any other resource I have = a token for. YES, I get a new token value to use every call, and there = is a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client.
    >> Personally I like that, because if I have an access_token, I = already think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I = wanted to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token" is not = the same as access tokens for an RS. The client gets a new "access = token" for each grant request, and for each API call to the AS, and the = client learns it can not make any more API calls for that specific = request when it does not get an "access token" back. This is a = completely different design pattern than calling an RS API with an = access token, and is a new design pattern for calling APIs. This adds = complexity to the client that it would not normally have, and I don't = think GNAP is the right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the = same thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical.
    >>
    >> The client is getting the "access token" from its API. It is = not using an "access_token" in other API calls to the AS.
    >> 
    >>
    >> Rotation of the access token and artifacts for ongoing = continuation responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87
    >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right = place to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me.
    >> 
    >>
    >>> 4) Clients that only want claims from the AS and no access = tokens will be required to support an API calling mechanism they would = not have to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make = with and without an access token is vanishingly small. The client has to = sign the initial request in some fashion, and it will sign the = continuation request in the same exact fashion, but now include an = access token in that request.
    >>
    >> Per my other point, there is no value to me in my = implementations of passing context back and forth between the client and = AS -- so it is extra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the = HTTP Authentication header is precluded from using it.
    >>
    >> 
    >>
    >> Clients making a request to an AS and not getting an access = token is a new design pattern. I think it has value and should be = included, but OAuth today shows us the immense value of getting access = tokens for calling APIs, and so we shouldn=E2=80=99t optimize away from = that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", there is = no mechanism for a client to delete the request, as the client is not = allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that = deleting a request does not seem like it is a "continue" operation.
    >> 
    >>
    >>>
    >>> 6) There is no standard identifier for the request. = Debugging and auditing are hampered by the client and AS having no = standard way to identifying a request. While one AS may provide a unique = URL for each grant request, another AS may use a persistent "access = token" to identify the grant request, and other ASs may issue a new = "access token" on each API call, providing no persistent identifier for = the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the = AS. How is interoperability harmed by different ASs having different = methods to identify their internal data elements? The client doesn=E2=80=99= t need any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was = referring to. How does a client developer identify the request when = communicating to the AS developer. Seems complicated.
    >> 
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    = >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    = >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.org
    >> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3D= AOvVaw0r39lH4qVOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub = Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL
    t: +44 (0)117 280 = 5120

    Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. = Moneyhub Financial Technology is = registered in England & Wales, company registration = number  06909772 .
    Moneyhub Financial Technology Limited 2019 =C2=A9

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

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

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub = Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL
    t: +44 (0)117 280 = 5120

    Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. = Moneyhub Financial Technology is = registered in England & Wales, company registration = number  06909772 .
    Moneyhub Financial Technology Limited 2019 =C2=A9

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

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

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



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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub = Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL
    t: +44 (0)117 280 = 5120

    Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. = Moneyhub Financial Technology is = registered in England & Wales, company registration = number  06909772 .
    Moneyhub Financial Technology Limited 2019 =C2=A9

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

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

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



    = --Apple-Mail=_F9F82488-9290-483E-A6A3-12DAE28E8FFD-- From nobody Tue Dec 15 13:11:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6345D3A1744 for ; Tue, 15 Dec 2020 13:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcWdfOAOup6i for ; Tue, 15 Dec 2020 13:11:34 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 73E7B3A1748 for ; Tue, 15 Dec 2020 13:11:33 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id i24so22542983edj.8 for ; Tue, 15 Dec 2020 13:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3fMSogffSXVYTtipFFd1kHqFU0I3f29GenlQCJHfGVA=; b=XcFA42YJIbq8XlcqTRUQk4IT3Gdy07sp8npkuYM1rYa5bYspeyNVLfeImezrWvqLpd yN2+JKBQmeyJRhPwOhWMhXpT+AvYFnUgO7xn0AD+bQJwTOXimhzyDrCk8Ki9vA9ofpXC mh1h3bNYr0tHmeDwbcWTb6lTSIJG+gXAhbBJM= 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=3fMSogffSXVYTtipFFd1kHqFU0I3f29GenlQCJHfGVA=; b=cYjdxzM9f1yS2a9nxB1UvhxaBz70JCS+0TDyZI5ll/xEGtziotAH469BVeQdvjzyV+ ULwNoQk8NoKzZUGdUhKWEdhl6apGj4bP8YQ2hIJY5tgiF+qb4asA3Aof926/jfr5WqPW aY+N3JhUt8irWSc+d6ZCNisAPLuPbbZPDxrn+iDL6GKHSV+mwHMF87ODnKaH/qJw38BI H4D9lFVENfraD7u3voHIlZN9gXLPm//6elSC3yLIiIuLrCIkf0KWnMxu933rMk3CFRrv wcpbDuOs9QcEZDZq81iIXFyzG/rMCHYtT5JUfTFO0jQN30FT0pQWzl5CtaascYoMjIjH CyVw== X-Gm-Message-State: AOAM530dxWBTcgZHcYUnqPFpNFpzwyY7i2Yc6jODIyN1u+h65kQakG/X 9sofDMBRill0qj+5GVIJpt+FZhMQ+JXRVTd1ysWRMoLd7eKypM+82GfcX3ub680A89FnEOL2vqq xvvlNOsInlyDiYDg= X-Google-Smtp-Source: ABdhPJxciu2uvwY2gFuvGvDDjccEjum47w/r3ziBPzuLeFEMx+2Jn9Y+/ORELXd9zPCa3lR0gEFrp7biqIQ+jGibtx4= X-Received: by 2002:a50:e00b:: with SMTP id e11mr31428700edl.303.1608066691404; Tue, 15 Dec 2020 13:11:31 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> In-Reply-To: <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> From: Dave Tonge Date: Tue, 15 Dec 2020 22:11:19 +0100 Message-ID: To: Justin Richer Cc: Fabien Imbault , Torsten Lodderstedt , txauth gnap , Steve Moore , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000eab19605b68733be" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 21:11:40 -0000 --000000000000eab19605b68733be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the detailed response. I think you make the points well and I'm now in favour of the PR. However I do think that to keep the consistency that keeps being discussed, that the tokens shouldn't be rotated. I also think it would be good to have a discussion about "grant management" and identifiers for a grant. Dave On Tue, 15 Dec 2020 at 17:30, Justin Richer wrote: > On Dec 15, 2020, at 10:50 AM, Dave Tonge wrote: > > > > The access token pattern has a lot of benefits, otherwise we wouldn=E2= =80=99t > have an entire OAuth ecosystem based on it > > *But what are the benefits in this particular use case?* The continuation > API is not like any other API - it is integral to the AS. There are quite= a > few extensions to OAuth that use client authentication rather than access > tokens. > > > Yes, and the propagation of that has lead to a mess in the OAuth world. > You=E2=80=99ve got re-definitions of client authentications at all differ= ent > endpoints, they=E2=80=99re technically allowed to vary between endpoints = (though I > don=E2=80=99t know of it happening in practice, that feels like a downgra= de attack > waiting to happen to someone). Then there=E2=80=99s the fact that all the= newest > security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 don= =E2=80=99t rely on client > authentication at all to achieve security. All of these work without the > client having credentials previously known to the AS, and we already know > that GNAP is going to need to live in this more dynamic world. We need to > think beyond what OAuth 2 has done in the past, and especially from our > perceptions and assumptions of the models that drive OAuth 2=E2=80=99s de= cisions, > lest we repeat its mistakes. > > Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2=80= =9D as a point. In > OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the server side, but i= n OAuth 2 we split > that into the RS concept. Even though in practice, a lot of RS=E2=80=99s = are still > integrated to the AS in some fashion because it=E2=80=99s a single servic= e, OAuth 2 > is clear about what=E2=80=99s expected to be known by each component. For= the AS as > currently defined in GNAP, I=E2=80=99m seeing three distinct functions. A= s per the > Terminology discussion, we don=E2=80=99t have explicit names for these ye= t: > > - starting a request; this is an endpoint to kick things off; it needs t= o > be able to look up the rights asked for by the client (if it knows the > client at all ahead of time) and make initial decisions about needed > interaction and follow up > - continuing a request; this is an API that needs to know the context of > the request itself, including which key it=E2=80=99s bound to; this is se= parate > from any identity of the client and possibly the user, but an AS > implementation that has access to those elements can use them > - interacting with the user; this is front-facing and in OAuth today is > already deployed as a separate service in some places, we should embrace > that at the very least (but doing so formally is a separate issue) > > Why separate these in this way? There is immense power in having a single > consistent way to start the process. The =E2=80=9Ccontinuation API=E2=80= =9D gives us an > HTTP-defined mechanism for managing a request over time, including the > simple case of returning information from the front channel, but people > have already raised the question of non-HTTP and self-hosted AS=E2=80=99s= , which > would probably want a different kind of continuation API to communicate t= o > the AS. The same thing with separating out the interaction: there are goi= ng > to be a lot of different ways to handle interaction out there, and not al= l > of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way that a si= mple > implementation might do. We=E2=80=99re defining a protocol based strongly= on HTTP > and JSON, but we should structure it in such a way that it can be extende= d > and translated elsewhere in a clear way. > > This all raises the question: if we can rely on a unique URL for > redirect-based interaction, why not here? The simple reason is that a URL > is the :only: mechanism we have in the front channel for passing > information, and we need to warn implementors against including sensitive > information in it, and we need to protect it with additional items. We ha= ve > access to more than just URLs when we=E2=80=99re dealing with the continu= ation API, > and we ought to make use of all of our tools in ways that are consistent > and make sense. > > From a previous email the advantages I see are: > - more data can be encoded in a token than in a uri (this seems more of > an edge case) > - it can be an identifier for the grant (I don't agree with this) > > > It allows the parts above to live separately, even if they don=E2=80=99t = HAVE to. > And it simplifies what we=E2=80=99re asking the client to do by making it > consistent with other parts of the ecosystem. The AS offering an API > doesn=E2=80=99t :have: to be different, and OpenID Connect showed us, wit= h the > UserInfo Endpoint, that that=E2=80=99s very much the case in practice. > > Having my client code do very similar things in slightly different ways i= s > not simpler. > > > Another question I have: *do we envisage granting access tokens to the RC > that will allow it to manage multiple grants*? > > > I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t bee= n brought up as a > use case to date. > > > I also think there will be confusion with the signing being used for > different things. Maybe it just needs to be called out in the spec that: > > Request 1: signature =3D client authentication > Request 2+: signature =3D proof of possession for access token > > > That=E2=80=99s more or less the intent of what=E2=80=99s in the specifica= tion right now, > and why all the signature methods, which are used for both client auth an= d > token possession, are all together in section 8 and not separated by use. > (With the caveat: it=E2=80=99s only client authentication in the first r= equest if > the AS knows about the client instance ahead of time, which isn=E2=80=99t= always > going to be true.) That all can likely be made clearer, as is always the > case with spec text. But you can use the signature methods with and witho= ut > access tokens, and it only gets used without in an initial call where you > don=E2=80=99t :have: an access token to present. > > Separating the different kinds of =E2=80=9Cclient authentication" out in = OAuth is > the source of some real confusion. Like right now, what happens if you tr= y > to combine a client assertion, signed request objects for PAR, and DPoP > proofs, all in a single request? All of these are optional and all of the= m > =E2=80=9Cdo client authentication=E2=80=9D in some arguable fashion. I=E2= =80=99ve worked on several > systems and implemented these things, and their interplay is really > confusing to manage and can go sideways really fast. And that=E2=80=99s j= ust the > work for a single endpoint, this gets repeated for introspection, > revocation, CIBA, device, and on. > > At the end of the day I=E2=80=99m in favor of giving the client developer= s a very > clear set of directions on what they need to do and how they need to acce= ss > things, and treating the continuation as a token-bound API is, to me, the > clearest pattern we can offer for this piece. > > =E2=80=94 Justin > > > > > > > > > > On Tue, 15 Dec 2020 at 15:33, Justin Richer wrote: > >> I agree with Fabien that the persistent identifier is a separate issue. >> The current spec re-uses the access token for this artifact, but that=E2= =80=99s >> potentially brittle and could be changed out for something else. There= =E2=80=99s an >> issue asking for expanding on the use cases for this functionality (whic= h >> hasn=E2=80=99t been addressed by this PR): >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >> >> A potentially-rotating URI would be just as brittle, and so having a >> single codified identifier for this artifact would be useful, but it doe= s >> assume some things about the nature of the AS. Every other use the clien= t >> has to manage the ongoing request over time doesn=E2=80=99t need an expl= icit >> identifier. Just like with OAuth-protected APIs, the server can determin= e >> the context not just from the URI but from the rest of the request, >> including the access token itself. This is both more common and more >> powerful than a strict reading of REST designs. It also follows the HATE= OS >> principles as the entire HTTP request is taken into account, including t= he >> access token and signature portions. >> >> I=E2=80=99ll also point out that the rotation of these credentials is al= so filed >> as a separate issue that=E2=80=99s not being addressed right now, so we = can revisit >> that discussion separately: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >> >> As for the name, we could give it a different label. We have this same >> pattern of issuing a resource-specific access token alongside a URL in t= he >> Dynamic Registration specification, both in OAuth ( >> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( >> https://openid.net/specs/openid-connect-registration-1_0.html#Registrati= onResponse). >> Here it=E2=80=99s called the =E2=80=9Cregistration access token=E2=80=9D= =E2=80=94 but what=E2=80=99s important >> there, as it is here, is that it=E2=80=99s not a different kind of artif= act that >> the client now has to figure out how to use, it=E2=80=99s an access toke= n plain and >> simple. In the OAuth world this is a bearer token, since that=E2=80=99s = what OAuth >> 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2=80= =99s what we=E2=80=99re >> looking to build on. This is also related to another future discussion >> about responses tying an access token to a specific API that=E2=80=99s t= old to the >> client, as we could potentially re-use those components and concepts her= e >> as well: >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 >> >> And finally, no speculation on the complexity is needed: I implemented >> this pattern several months ago during the design team discussions when = we >> were considering this pattern, and the code is all online for people to >> see. >> >> https://github.com/bspk/oauth.xyz-java/ >> >> On the AS side, the most interesting code to this discussion is in the >> TransactionEndpoint class: >> >> >> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/b= spk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java >> >> Here, you=E2=80=99ll see that on initial request, the server looks up th= e client >> to see if it=E2=80=99s been registered, but after that, it makes sure th= at the >> token and key are appropriate for the ongoing request. From the client s= ide >> it=E2=80=99s even simpler. The client=E2=80=99s got a small service func= tion to manage the >> different signature methods that are implemented, and all of them can ta= ke >> in an optional access token: >> >> >> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/b= spk/oauth/xyz/http/SigningRestTemplateService.java >> >> The heavy lift is doing the actual signing, and you need that in order t= o >> start the process anyway. Managing the access token as an artifact to us= e >> at the API is completely trivial since the client already needs to manag= e >> its own state internally to do any of this. And note that all of this is >> changed from how it was before: Previously, the XYZ Protocol had used a >> =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the client = would use to >> continue the request. However, this simple model was limiting, and the >> design team adopted XAuth=E2=80=99s model of continuation being an API. = In doing >> so, we made it like all of the other APIs the client is going to call: i= n >> the initial state, it doesn=E2=80=99t have any kind of access rights, it= =E2=80=99s just >> calling. From that initial call forward, the AS just needs to know that = the >> token and key match what it expects. >> >> In summary, my views are: >> - The access token pattern has a lot of benefits, otherwise we wouldn= =E2=80=99t >> have an entire OAuth ecosystem based on it >> - Magic URIs have a lot of drawbacks which are well understood; while >> they can be mitigated, they can also be avoided >> - Continuation is an API, and treating it like the other kinds of API >> the client would call makes sense >> - Calling this by a special name, like =E2=80=9Cgrant access token=E2= =80=9D or >> =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should funct= ion like any other >> access token >> - The heavy lift for clients is on protecting the message >> cryptographically, which they need to do anyway >> >> =E2=80=94 Justin >> >> >> On Dec 15, 2020, at 7:50 AM, Dave Tonge wrote: >> >> The persistent identifier is not a different issue, the current access >> token is used to reference an existing grant >> >> >> >> It may not be more difficult for a client to *use* an access token at >> the AS / RS. But there is definitely an overhead on the client to >> *manage* this separate access token. >> >> >> >> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault >> wrote: >> >>> I think we always said the access token was different, and handled as a >>> bound token. >>> >>> But it doesn't mean it's more difficult for the client that already >>> needs to be able to handle tokens anyway (bearer or not, both cases cou= ld >>> occur). It's mostly consolidating the logic. >>> >>> You're anticipating a lot of issues which have no specific reason to >>> occur, such as "can't be used with the token management APIs?". The >>> management API is part of the same general flow. >>> Anticipating issues with rotation is useful, but there are also many >>> ways it can be hard to manage through a stateful approach too. And >>> fundamentally, having everything in a common model (both for the intern= als >>> of the AS and for the API calls) will help improve by a large margin wh= at >>> is probably the weakest point in today's infrastructure. But it's early= to >>> be definitive as to the downstream impact either way. >>> >>> As for a persistent identifier instead of a continuation API, and >>> generally the end of your message, it's a totally unrelated issue to th= is >>> PR, so I suggest we don't discuss that here, but in a separate issue if >>> needed. >>> >>> Fabien >>> >>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>> wrote: >>> >>>> So we've established that this is a different access token, that >>>> requires different handling at the client. So keeping it could cause m= ore >>>> confusion? >>>> >>>> As an RC, I will have to store the continue `uri` as although it could >>>> be static it could also be dynamic. Why do I need to store an access t= oken >>>> as well. It brings me no benefit as an RC, in fact it brings more >>>> complexity. As I will now need to manage multiple types of tokens with >>>> different lifecycles: >>>> >>>> *Continuation token* >>>> - can only be used at the continue endpoint (the name of which is >>>> confusing as I can use this endpoint to revoke a grant or get metadata= on >>>> the grant). >>>> - may be rotated each time it is used, or may not be >>>> - provided in the `continue` section of the response >>>> - must be sender-constrained >>>> - can't be used with the token management APIs? >>>> - can be used to identify the grant when making subsequent grants >>>> >>>> *Access token(s) to use at RS* >>>> - can only be used at the specified RS >>>> - may be sender constrained >>>> - when used at the RS, will not result in rotation >>>> >>>> From my perspective, most use-cases will require the RC to have a >>>> persistent identifier for the grant. Why not bring this into the proto= col >>>> and let the AS provide this persistent identifier (through the form of= the >>>> continue uri). Using a rotating access token as a persistent identifie= r >>>> doesn't seem like the right choice. >>>> >>>> I see no security benefit to having the continuation access token. It >>>> doesn't matter if the continue uri leaks as it is useless without an >>>> accompanying signature, i.e. any security benefit of having an access = token >>>> is already provided by having a signature. >>>> >>>> The only benefits that I can see are: >>>> - If the AS wants to be fully stateless, then you can encode more dat= a >>>> in a token than in a uri >>>> - If the AS wants to have a static endpoint for CRUD operations on th= e >>>> grant >>>> - To allow the AS to identity a previous grant >>>> >>>> If we dropped the access token for the continue endpoint and rather >>>> mandated a dynamic uri this would make things conceptually easier to >>>> understand, easier for the RC to implement, easier to debug and less c= hance >>>> of errors when rotating tokens (i.e. race conditions could be quite li= kely >>>> if the AS always rotates the token) >>>> >>>> *One-off grant with no continuation or ongoing management:* >>>> RC sends signature and metadata, no `continue` response provided, >>>> therefore no grant management possible >>>> >>>> *Grant with ongoing management* >>>> RC sends signature and metadata, AS responds with a continue uri that >>>> has these purposes: >>>> - can be used by the RC to continue/update, read or revoke the grant >>>> - can be used by the RC when making a new grant to identify the >>>> previous grant >>>> >>>> As an RC the only permanent items I need to store are: >>>> - the continue uri associated with the grant >>>> - any access tokens I receive for the grant >>>> >>>> Dave >>>> >>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >>>> wrote: >>>> >>>>> Hi Torsten, >>>>> >>>>> You're right on both accounts. >>>>> - for the first remark, it fits quite nicely the init request / >>>>> continuation pattern >>>>> - for the second remark, it is a sort of handle for the >>>>> continuation request, which will eventually lead to the issuance or r= efresh >>>>> of standard access tokens >>>>> >>>>> Having a specific name is a possibility, I actually suggested that to= o >>>>> at some point. >>>>> >>>>> Fabien >>>>> >>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> >>>>>> Hi Fabien, >>>>>> >>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>> fabien.imbault@gmail.com>: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > On the contrary your feedback is most welcome. >>>>>> > >>>>>> > It doesn't accept any token, it needs the particular token as >>>>>> described in 3.1 and which is not a bearer token (that's what the "k= ey" : >>>>>> true parameter is supposed to convey). >>>>>> > >>>>>> > Let us know if you need more clarifications. >>>>>> >>>>>> Thanks for the clarification. I think only accepting this kind of >>>>>> token at the continuation is a good idea otherwise the AS would need= to be >>>>>> able to parse and understand all sorts of access tokens. >>>>>> >>>>>> Conceptually, I like the idea to treat the continuation as another >>>>>> kind of resource. However, here are some observations I want to shar= e with >>>>>> you: >>>>>> - This resource is different as it will issue other access tokens (o= f >>>>>> this kind) to be used in subsequent continuation requests. This requ= ires >>>>>> different handing on the client side. >>>>>> - This access token (if I understand correctly) is (or at least feel= s >>>>>> like) a handle for the underlying grant. So it is kind of the super = access >>>>>> token to obtain other access tokens. >>>>>> >>>>>> I would consider using a different term to refer to this special >>>>>> access token, grant token or grant handle for example, in order to p= revent >>>>>> confusion. >>>>>> >>>>>> best regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> > >>>>>> > Best >>>>>> > Fabien >>>>>> > >>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>> > Hi all, >>>>>> > >>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me questio= n seems >>>>>> naive. >>>>>> > >>>>>> > After having skimmed through the current draft and the PR, I=E2=80= =98m not >>>>>> sure whether the continuation requests accepts any access token issu= ed to >>>>>> the RC or the particular access token returned in the =E2=80=9Econti= nue=E2=80=9C element in >>>>>> section 3.1.. >>>>>> > >>>>>> > Can you please shed some light on this? >>>>>> > >>>>>> > kind regards, >>>>>> > Torsten. >>>>>> > >>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>> fabien.imbault@gmail.com>: >>>>>> >> >>>>>> >> =EF=BB=BF >>>>>> >> You're completely right. Allowing the dev to be lazy is a very >>>>>> good thing in general, because it's what we know will work :-) >>>>>> >> >>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >>>>>> =C3=A9crit : >>>>>> >> Hi Fabien, >>>>>> >> >>>>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>>>> sort of in the back of my mind, it isn't a huge risk there. So I act= ually >>>>>> agree with Dick there. Something doesn't sit right with me for the u= nique >>>>>> URL solution, so I don't like it and came up with a hypothetical tha= t seems >>>>>> like it could be a down side. >>>>>> >> >>>>>> >> I still think the access token model with the signed request is >>>>>> the way I'd like to go, because again, it's a mechanism I'd be imple= menting >>>>>> anyway to talk to any 'normal' resource. The fact is there is _somet= hing_ >>>>>> representing context that has to pass back and forth here, whether t= hat is >>>>>> an access token (which I feel like is more flexible for extensions e= tc), a >>>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy develo= per ;) >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >> Again speaking in my own name here. >>>>>> >> >>>>>> >> Dick, we know you'd prefer to have a different design, but this P= R >>>>>> shouldn't be about that. >>>>>> >> >>>>>> >> Back on your 3 items : >>>>>> >> >>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>> decided that wouldn't be how that would work. We have a client insta= nce >>>>>> that allows a more generic and flexible pattern (which BTW also allo= ws what >>>>>> you want) >>>>>> >> >>>>>> >> 2) instead of blame arguments of who's less >>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversation= s, I >>>>>> suggest we speak in less abstract terms and ask ourselves what that = means >>>>>> in practice for devs. Stephen and several others (myself included) h= ave >>>>>> expressed that it wouldn't be harder to implement, it would even sim= plify >>>>>> things quite a lot. If you disagree please send us a code sample to = really >>>>>> show that point by example, because that's really not obvious. >>>>>> >> >>>>>> >> 3) "If someone has the client credentials, they can impersonate >>>>>> the client, and all bets are off." Are you seriously making this arg= ument? >>>>>> Because if you have a better proposal than using cryptographic keys,= I'm >>>>>> all hears. You make it look like there's a problem, while in reality= we're >>>>>> only relying on the basic assumption of all modern digital communica= tions. >>>>>> >> >>>>>> >> And more importantly you never responded to the issues of how to >>>>>> avoid the security pitfalls of what you proposed. >>>>>> >> >>>>>> >> Fabien >>>>>> >> >>>>>> >> >>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>>>>> =C3=A9crit : >>>>>> >> >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>>> wrote: >>>>>> >> But from the spec: >>>>>> >> " >>>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>>> identify itself by including the client field of the request... >>>>>> >> ... >>>>>> >> key (object / string) : The public key of the RC to be used in >>>>>> this request as described in {{request-key}}. This field is REQUIRED= . >>>>>> >> ... >>>>>> >> " >>>>>> >> So on the initial request, the key will be there. >>>>>> >> >>>>>> >> The client field can be an object or a string. If the client is >>>>>> pre-registered, then a string could be provided instead of an object= . >>>>>> >> >>>>>> >> >>>>>> >> If you don't have the access token, then how do you differentiate >>>>>> between two requests from the same web application by two different = users? >>>>>> Is the web application supposed to have different credentials for ev= ery >>>>>> request? >>>>>> >> >>>>>> >> The AS returns a URI for manipulating the request. I would change >>>>>> the spec so that each request would have a unique URI. This is the u= sually >>>>>> RESTful pattern that the resource (the grant request) has an URI. >>>>>> >> >>>>>> >> >>>>>> >> So in this case, the easy way out is to pass the access token to >>>>>> the client, who then, as i stated before, treats the continue reques= t as a >>>>>> RS call (albeit a specialized version of the RS where the RS is the = AS) OR >>>>>> to use the unique URL, >>>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>>> (What would be the point of that attack, I don't know, I guess if so= meone >>>>>> had the client credentials but not any subjects/resources they could= try to >>>>>> intercept the grant via continue... I just don't feel right locking = things >>>>>> down to unique URLs that way.) >>>>>> >> >>>>>> >> If someone has the client credentials, they can impersonate the >>>>>> client, and all bets are off. >>>>>> >> >>>>>> >> LOTS of RS servers return a resource specific URL -- my proposal >>>>>> is no different. >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>>> wrote: >>>>>> >> Hi Stephen >>>>>> >> >>>>>> >> The client is signing the first request. The key *might* be in th= e >>>>>> body. The client is signing all the subsequent requests as well. The >>>>>> "access token" is not needed by the client to prove it is authorized= as the >>>>>> client is proving it is the same client again. >>>>>> >> >>>>>> >> In other words, I don't see the need for an access token, so it >>>>>> does not need to be put in a URL or an auth header. >>>>>> >> >>>>>> >> If a developer really, really wants to hand context back to the >>>>>> client for subsequent calls, they can put it in the URL or some othe= r >>>>>> method. Putting it in the HTTP Authorization header is confusing bec= ause it >>>>>> is NOT an access token -- it is the context of the request. >>>>>> >> >>>>>> >> =E1=90=A7 >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>>> wrote: >>>>>> >> Even though I've only been lightly following things, I feel the >>>>>> need to voice my preference as a developer since I will probably som= eday >>>>>> have to either write a RC or RS... >>>>>> >> >>>>>> >> The way I see it is the RC makes the initial request to the AS as >>>>>> part of this request, it provides it's key in the body... (So no use= of the >>>>>> Authorization header) >>>>>> >> At this point that request, represented by the continue URL + >>>>>> "Access Token", from my lazy developer standpoint, is a Resource End= point >>>>>> and Access Token, and the AS is acting as a specialized RS in this c= ase. >>>>>> >> So my client posts to whatever URL with the 'access token' in the >>>>>> authorization header, just like acting on any other resource I have = a token >>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>> decision point of "Do I have another continue, or do I have a real t= oken >>>>>> for the resource..." But the mechanism is the same to me in the clie= nt. >>>>>> >> Personally I like that, because if I have an access_token, I >>>>>> already think "Put it in the auth header." >>>>>> >> >>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>> wrote: >>>>>> >> inline ... >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>> wrote: >>>>>> >> Others had already responded to this previous thread, but I wante= d >>>>>> to add a couple points to clarify some things. >>>>>> >> >>>>>> >>> 3) What the client has to do with the "access token" is not the >>>>>> same as access tokens for an RS. The client gets a new "access token= " for >>>>>> each grant request, and for each API call to the AS, and the client = learns >>>>>> it can not make any more API calls for that specific request when it= does >>>>>> not get an "access token" back. This is a completely different desig= n >>>>>> pattern than calling an RS API with an access token, and is a new de= sign >>>>>> pattern for calling APIs. This adds complexity to the client that it= would >>>>>> not normally have, and I don't think GNAP is the right place to star= t a new >>>>>> design pattern. >>>>>> >>> >>>>>> >> >>>>>> >> I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole >>>>>> point of the design is that the client would be doing the same thing= with >>>>>> the access token at the AS that it does with the RS by re-using the = access >>>>>> token structure. Can you please describe what the differences are, a= part >>>>>> from the rotation? Presentation of the token and signing of the mess= age are >>>>>> identical. >>>>>> >> >>>>>> >> The client is getting the "access token" from its API. It is not >>>>>> using an "access_token" in other API calls to the AS. >>>>>> >> >>>>>> >> >>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>> continuation responses is a separate issue to be discussed: >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >> >>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right pla= ce to >>>>>> have new designs =E2=80=94 not that this is one. >>>>>> >> >>>>>> >> You are proposing a new way for an API to provide context for >>>>>> subsequent API calls. Looks out of scope to me. >>>>>> >> >>>>>> >> >>>>>> >>> 4) Clients that only want claims from the AS and no access token= s >>>>>> will be required to support an API calling mechanism they would not = have to >>>>>> support otherwise. >>>>>> >> >>>>>> >> Correct, but the delta between the calls a client would make with >>>>>> and without an access token is vanishingly small. The client has to = sign >>>>>> the initial request in some fashion, and it will sign the continuati= on >>>>>> request in the same exact fashion, but now include an access token i= n that >>>>>> request. >>>>>> >> >>>>>> >> Per my other point, there is no value to me in my implementations >>>>>> of passing context back and forth between the client and AS -- so it= is >>>>>> extra work providing no value. >>>>>> >> >>>>>> >> Also, any client authentication mechanism that wants to use the >>>>>> HTTP Authentication header is precluded from using it. >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> Clients making a request to an AS and not getting an access token >>>>>> is a new design pattern. I think it has value and should be included= , but >>>>>> OAuth today shows us the immense value of getting access tokens for = calling >>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>> >> >>>>>> >>> >>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>> mechanism for a client to delete the request, as the client is not a= llowed >>>>>> to make a call without an "access token". >>>>>> >> >>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>>> is telling this client instance that it can=E2=80=99t do anything el= se with this >>>>>> ongoing request. If the AS wants to allow the client to manage it, i= t will >>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fi= eld. >>>>>> >> >>>>>> >> There is nuance in that intention. A related concern is that >>>>>> deleting a request does not seem like it is a "continue" operation. >>>>>> >> >>>>>> >> >>>>>> >>> >>>>>> >>> 6) There is no standard identifier for the request. Debugging an= d >>>>>> auditing are hampered by the client and AS having no standard way to >>>>>> identifying a request. While one AS may provide a unique URL for eac= h grant >>>>>> request, another AS may use a persistent "access token" to identify = the >>>>>> grant request, and other ASs may issue a new "access token" on each = API >>>>>> call, providing no persistent identifier for the request. >>>>>> >> >>>>>> >> Debugging and auditing this kind of thing are functions of the AS= . >>>>>> How is interoperability harmed by different ASs having different met= hods to >>>>>> identify their internal data elements? The client doesn=E2=80=99t ne= ed any >>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the= next steps for >>>>>> continuing the negotiation. >>>>>> >> >>>>>> >> Debugging between the client and the AS was what I was referring >>>>>> to. How does a client developer identify the request when communicat= ing to >>>>>> the AS developer. Seems complicated. >>>>>> >> >>>>>> >> =E1=90=A7 >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >> =E1=90=A7 >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> >>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo= /txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0= IQPJJYtSpI >>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>>> -- >>>> Dave Tonge >>>> CTO >>>> [image: Moneyhub Enterprise] >>>> >>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>>> 6FL >>>> t: +44 (0)117 280 5120 >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at *https://register.fca.org.= uk/ >>>> *. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772 . >>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6= FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000eab19605b68733be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for the detailed response.

    I think y= ou make the points well and I'm now in favour of the PR.
    However I= do think that to keep the consistency that keeps being discussed, that the= tokens shouldn't be rotated.=C2=A0

    I also think it woul= d be good to have a discussion about "grant management" and ident= ifiers for a grant.

    Dave

    On Tue, 15 Dec 2020 at 17:30, = Justin Richer <jricher@mit.edu>= ; wrote:
    On Dec 15, 2020, at 10:50 AM, Dave Tonge= <dave.tong= e@moneyhub.com> wrote:

    >=C2=A0The access token pattern has a lot of benefits, otherwise = we wouldn=E2=80=99t have an entire OAuth ecosystem based on it
    =

    But what are the benefits=C2=A0in = this particular use case? The continuation API is not like any other AP= I - it is integral to the AS. There are quite a few extensions to OAuth tha= t use client authentication rather than access tokens.

    Yes, and the propagation of that has lead to = a mess in the OAuth world. You=E2=80=99ve got re-definitions of client auth= entications at all different endpoints, they=E2=80=99re technically allowed= to vary between endpoints (though I don=E2=80=99t know of it happening in = practice, that feels like a downgrade attack waiting to happen to someone).= Then there=E2=80=99s the fact that all the newest security mechanisms we h= ave =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 don=E2=80=99t rely on client a= uthentication at all to achieve security. All of these work without the cli= ent having credentials previously known to the AS, and we already know that= GNAP is going to need to live in this more dynamic world. We need to think= beyond what OAuth 2 has done in the past, and especially from our percepti= ons and assumptions of the models that drive OAuth 2=E2=80=99s decisions, l= est we repeat its mistakes.=C2=A0

    Also, I want to = challenge this idea of =E2=80=9Cintegral to the AS=E2=80=9D as a point. In = OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the server side, but in = OAuth 2 we split that into the RS concept. Even though in practice, a lot o= f RS=E2=80=99s are still integrated to the AS in some fashion because it=E2= =80=99s a single service, OAuth 2 is clear about what=E2=80=99s expected to= be known by each component. For the AS as currently defined in GNAP, I=E2= =80=99m seeing three distinct functions. As per the Terminology discussion,= we don=E2=80=99t have explicit names for these yet:

    =C2=A0- starting a request; this is an endpoint to kick things off; it n= eeds to be able to look up the rights asked for by the client (if it knows = the client at all ahead of time) and make initial decisions about needed in= teraction and follow up
    =C2=A0- continuing a request; this is an API t= hat needs to know the context of the request itself, including which key it= =E2=80=99s bound to; this is separate from any identity of the client and p= ossibly the user, but an AS implementation that has access to those element= s can use them
    =C2=A0- interacting with the user; this is front-f= acing and in OAuth today is already deployed as a separate service in some = places, we should embrace that at the very least (but doing so formally is = a separate issue)

    Why separate these in this way? = There is immense power in having a single consistent way to start the proce= ss. The =E2=80=9Ccontinuation API=E2=80=9D gives us an HTTP-defined mechani= sm for managing a request over time, including the simple case of returning= information from the front channel, but people have already raised the que= stion of non-HTTP and self-hosted AS=E2=80=99s, which would probably want a= different kind of continuation API to communicate to the AS. The same thin= g with separating out the interaction: there are going to be a lot of diffe= rent ways to handle interaction out there, and not all of them will be =E2= =80=9Cintegral=E2=80=9D to the AS in the way that a simple implementation m= ight do. We=E2=80=99re defining a protocol based strongly on HTTP and JSON,= but we should structure it in such a way that it can be extended and trans= lated elsewhere in a clear way.

    This all raises the question: i= f we can rely on a unique URL for redirect-based interaction, why not here?= The simple reason is that a URL is the :only: mechanism we have in the fro= nt channel for passing information, and we need to warn implementors agains= t including sensitive information in it, and we need to protect it with add= itional items. We have access to more than just URLs when we=E2=80=99re dea= ling with the continuation API, and we ought to make use of all of our tool= s in ways that are consistent and make sense.

    Fr= om a previous email the advantages I see are:
    =C2=A0- more data can be encoded in a token than in a uri (this seems = more of an edge case)
    =C2=A0- it can be a= n identifier for the grant (I don't agree with this)
    <= /blockquote>

    It allows the parts above to live separatel= y, even if they don=E2=80=99t HAVE to. And it simplifies what we=E2=80=99re= asking the client to do by making it consistent with other parts of the ec= osystem. The AS offering an API doesn=E2=80=99t :have: to be different, and= OpenID Connect showed us, with the UserInfo Endpoint, that that=E2=80=99s = very much the case in practice.=C2=A0

    Having my cl= ient code do very similar things in slightly different ways is not simpler.=


    Another question I have:= do we envisage granting access tokens to the RC that will allow it to m= anage multiple grants?=C2=A0=C2=A0
    <= br>
    I don=E2=80=99t see that happening, personally, and it hasn= =E2=80=99t been brought up as a use case to date.=C2=A0


    I also think there will be confusion with th= e signing being used for different things. Maybe it just needs to be called= out in the spec that:

    Request 1: signature =3D client authentication
    Request 2+: signature =3D proof of possessio= n for access token

    =

    That=E2=80=99s more or less the intent of = what=E2=80=99s in the specification right now, and why all the signature me= thods, which are used for both client auth and token possession, are all to= gether in section 8 and not separated by use. =C2=A0(With the caveat: it=E2= =80=99s only client authentication in the first request if the AS knows abo= ut the client instance ahead of time, which isn=E2=80=99t always going to b= e true.) That all can likely be made clearer, as is always the case with sp= ec text. But you can use the signature methods with and without access toke= ns, and it only gets used without in an initial call where you don=E2=80=99= t :have: an access token to present.

    Separating th= e different kinds of =E2=80=9Cclient authentication" out in OAuth is t= he source of some real confusion. Like right now, what happens if you try t= o combine a client assertion, signed request objects for PAR, and DPoP proo= fs, all in a single request? All of these are optional and all of them =E2= =80=9Cdo client authentication=E2=80=9D in some arguable fashion. I=E2=80= =99ve worked on several systems and implemented these things, and their int= erplay is really confusing to manage and can go sideways really fast. And t= hat=E2=80=99s just the work for a single endpoint, this gets repeated for i= ntrospection, revocation, CIBA, device, and on.

    At= the end of the day I=E2=80=99m in favor of giving the client developers a = very clear set of directions on what they need to do and how they need to a= ccess things, and treating the continuation as a token-bound API is, to me,= the clearest pattern we can offer for this piece.

    =C2=A0=E2=80=94 Justin


    <= br>






    On Tue, 15 Dec 2020 at 15:33, Justin Richer <jricher@mit.edu> w= rote:
    I agr= ee with Fabien that the persistent identifier is a separate issue. The curr= ent spec re-uses the access token for this artifact, but that=E2=80=99s pot= entially brittle and could be changed out for something else. There=E2=80= =99s an issue asking for expanding on the use cases for this functionality = (which hasn=E2=80=99t been addressed by this PR):
    A potentially-rotating URI would be just as brittle, and= so having a single codified identifier for this artifact would be useful, = but it does assume some things about the nature of the AS. Every other use = the client has to manage the ongoing request over time doesn=E2=80=99t need= an explicit identifier. Just like with OAuth-protected APIs, the server ca= n determine the context not just from the URI but from the rest of the requ= est, including the access token itself. This is both more common and more p= owerful than a strict reading of REST designs. It also follows the HATEOS p= rinciples as the entire HTTP request is taken into account, including the a= ccess token and signature portions.=C2=A0

    I=E2=80= =99ll also point out that the rotation of these credentials is also filed a= s a separate issue that=E2=80=99s not being addressed right now, so we can = revisit that discussion separately:


    =
    As for the name, we could give it a different label. We have thi= s same pattern of issuing a resource-specific access token alongside a URL = in the Dynamic Registration specification, both in OAuth (https://tools.ie= tf.org/html/rfc7592#section-3) and OpenID Connect (https://openid.net/specs/openid-connect-registration-1_0.= html#RegistrationResponse). Here it=E2=80=99s called the =E2=80=9Cregis= tration access token=E2=80=9D =E2=80=94 but what=E2=80=99s important there,= as it is here, is that it=E2=80=99s not a different kind of artifact that = the client now has to figure out how to use, it=E2=80=99s an access token p= lain and simple. In the OAuth world this is a bearer token, since that=E2= =80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll be a bound token= , as that=E2=80=99s what we=E2=80=99re looking to build on. This is also re= lated to another future discussion about responses tying an access token to= a specific API that=E2=80=99s told to the client, as we could potentially = re-use those components and concepts here as well:

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

    And finally, no speculation on the complexi= ty is needed: I implemented this pattern several months ago during the desi= gn team discussions when we were considering this pattern, and the code is = all online for people to see.=C2=A0


    On the AS side, the most = interesting code to this discussion is in the TransactionEndpoint class:


    Here, you=E2=80=99ll see that o= n initial request, the server looks up the client to see if it=E2=80=99s be= en registered, but after that, it makes sure that the token and key are app= ropriate for the ongoing request. From the client side it=E2=80=99s even si= mpler. The client=E2=80=99s got a small service function to manage the diff= erent signature methods that are implemented, and all of them can take in a= n optional access token:=C2=A0


    The heavy lift= is doing the actual signing, and you need that in order to start the proce= ss anyway. Managing the access token as an artifact to use at the API is co= mpletely trivial since the client already needs to manage its own state int= ernally to do any of this. And note that all of this is changed from how it= was before: Previously, the XYZ Protocol had used a =E2=80=9Ctransaction h= andle=E2=80=9D returned by the AS that the client would use to continue the= request. However, this simple model was limiting, and the design team adop= ted XAuth=E2=80=99s model of continuation being an API. In doing so, we mad= e it like all of the other APIs the client is going to call: in the initial= state, it doesn=E2=80=99t have any kind of access rights, it=E2=80=99s jus= t calling. From that initial call forward, the AS just needs to know that t= he token and key match what it expects.=C2=A0

    In s= ummary, my views are:
    =C2=A0- The access token pattern has a lot = of benefits, otherwise we wouldn=E2=80=99t have an entire OAuth ecosystem b= ased on it
    =C2=A0- Magic URIs have a lot of drawbacks which are w= ell understood; while they can be mitigated, they can also be avoided
    =
    =C2=A0- Continuation is an API, and treating it like the other kinds o= f API the client would call makes sense
    =C2=A0- Calling this by a= special name, like =E2=80=9Cgrant access token=E2=80=9D or =E2=80=9Ccontin= uation access token=E2=80=9D is fine, but it should function like any other= access token
    =C2=A0- The heavy lift for clients is on protecting= the message cryptographically, which they need to do anyway

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


    On Dec 15, 2020, at 7:50 AM, Dave Tonge <dave.tonge@moneyhub.com>= ; wrote:

    The persistent identif= ier=C2=A0is not a different issue, the current access token is used to reference an existing grant=C2=A0

    It may not be more difficult for a client to = use an access token at the AS / RS. But there=C2=A0is definitely an ove= rhead on the client to manage=C2=A0this separate access token.=C2=A0=



    On Tue, 15 Dec 2020 at 12= :10, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I think we always said= the access token was different, and handled as a bound token.

    But it doesn't mean it's more difficult for the client that = already needs to be able to handle tokens anyway (bearer or not, both cases= could occur). It's mostly consolidating the logic.

    =
    You're anticipating a lot of issues which have no specific r= eason to occur, such as "can't be used with the token management APIs?".= The management API is part of the same general flow.
    Anticipating is= sues with rotation is useful, but there are also many ways it can be hard t= o manage through a stateful approach too. And fundamentally, having everyth= ing in a common model (both for the internals of the AS and for the API cal= ls) will help improve by a large margin what is probably the weakest point = in today's infrastructure. But it's early to be definitive as to th= e downstream impact either way.=C2=A0 =C2=A0

    As for a = persistent identifier instead of a continuation API, and generally the end = of your message, it's a totally unrelated issue to this PR, so I sugges= t we don't discuss that here, but in a separate issue if needed.=

    Fabien

    On Tue, Dec 15, 2020 at 11:08 A= M Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've establi= shed that this is a different access token, that requires different handlin= g at the client. So keeping it could cause more confusion?
    As an RC, I will have to store the continue `uri` a= s although it could be static it could also be dynamic. Why do I need to st= ore an access token as well.=C2=A0It brings me no benefit as an RC, in fact= it brings more complexity. As I will now need to manage multiple types of = tokens with different lifecycles:

    =C2=A0 - can only be u= sed at the continue endpoint (the name of which is confusing as I can use t= his endpoint to revoke a grant or get metadata on the grant).
    =C2=A0- may be rotated each time it is used, or may not be
    =C2=A0- provided in the `continue` section of the response
    =C2=A0- must be sender-constrained
    =C2=A0- can't= be used with the token management APIs?
    =C2=A0- can be us= ed to identify the grant when making subsequent grants
    Access token(s) to use at RS
    = =C2=A0=C2=A0- can only be used at the specified RS
    =C2= =A0 - may be sender constrained
    =C2=A0 - when used at the = RS, will not result in rotation

    From= my perspective, most use-cases will require the RC to have a persistent id= entifier for the grant. Why not bring this into the protocol and let the AS= provide this persistent identifier (through the form of the continue uri).= Using a rotating access token as a persistent identifier doesn't seem = like the right choice.=C2=A0

    I see n= o security benefit to having the continuation access token. It doesn't = matter if the continue uri leaks as it is useless without an accompanying s= ignature, i.e. any security benefit of having an access token is already pr= ovided by having a signature.

    The on= ly benefits that I can see are:
    =C2=A0- If the AS wants to= be fully stateless, then you can encode more data in a token than in a uri=
    =C2=A0- If the AS wants to have a static endpoint for CRU= D operations on the grant
    =C2=A0- To allow the AS to ident= ity a previous grant

    If we dropped t= he access token for the continue endpoint and rather mandated a dynamic uri= this would make things conceptually easier to understand, easier for the R= C to implement, easier to debug and less chance of errors when rotating tok= ens (i.e. race conditions could be quite likely if the AS always rotates th= e token)

    One-off grant with no co= ntinuation or ongoing management:
    RC sends signature a= nd metadata, no `continue` response provided, therefore no grant management= possible

    Grant with ongoing mana= gement
    RC sends signature and metadata, AS responds wi= th a continue uri that has these purposes:
    =C2=A0- can be = used by the RC to continue/update, read or revoke the grant

    As an RC the only perm= anent items I need to store are:
    =C2=A0- the continue uri = associated with the grant
    =C2=A0- any access tokens I rece= ive for the grant

    Dave
    On Tue, = 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Tor= sten,=C2=A0

    You're right on both accounts.=C2=A0
    - for the first remark, it fits quite nicely the init request=C2=A0 = / continuation pattern=C2=A0
    - for the second remark, it is a sor= t of handle for the continuation=C2=A0request, which will eventually lead t= o the issuance or refresh of standard access tokens=C2=A0

    Having a specific=C2=A0name is a possibility, I actually suggested = that too at some point.=C2=A0

    Fabien
    On Tue, = Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

    Moneyhub Enterprise is a trading style of Moneyhub Fin= ancial Technology Limited which is authorised and regulated by the Financia= l Conduct Authority ("FCA"). Moneyhub Financial Technology is ent= ered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/<= /span>. Moneyhub Financial Technology is registered in England & Wa= les, company registration number 06909772. Moneyhub Financial Technology Li= mited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friar= y, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is su= bject to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthoris= ed and unlawful. Whilst reasonable efforts are made to ensure that any atta= chments are virus-free, it is the recipient's sole responsibility to sc= an all attachments for viruses. All calls and emails to and from this compa= ny may be monitored and recorded for legitimate purposes relating to this c= ompany's business. Any opinions expressed in this email (or in any atta= chments) are those of the author and do not necessarily represent the opini= ons of Moneyhub Financial Technology Limited or of any other group company.=




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

    Moneyhub Enterprise is a trading style of Moneyhub Fin= ancial Technology Limited which is authorised and regulated by the Financia= l Conduct Authority ("FCA"). Moneyhub Financial Technology is ent= ered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/<= /span>. Moneyhub Financial Technology is registered in England & Wa= les, company registration number 06909772. Moneyhub Financial Technology Li= mited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friar= y, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is su= bject to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthoris= ed and unlawful. Whilst reasonable efforts are made to ensure that any atta= chments are virus-free, it is the recipient's sole responsibility to sc= an all attachments for viruses. All calls and emails to and from this compa= ny may be monitored and recorded for legitimate purposes relating to this c= ompany's business. Any opinions expressed in this email (or in any atta= chments) are those of the author and do not necessarily represent the opini= ons of Moneyhub Financial Technology Limited or of any other group company.=



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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

    Moneyhub Enterprise is a trading style of Moneyhub Fin= ancial Technology Limited which is authorised and regulated by the Financia= l Conduct Authority ("FCA"). Moneyhub Financial Technology is ent= ered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/<= /span>. Moneyhub Financial Technology is registered in England & Wa= les, company registration number 06909772. Moneyhub Financial Technology Li= mited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friar= y, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is su= bject to copyright, and the information in it is confidential. Use of this = email or of any information in it other than by the addressee is unauthoris= ed and unlawful. Whilst reasonable efforts are made to ensure that any atta= chments are virus-free, it is the recipient's sole responsibility to sc= an all attachments for viruses. All calls and emails to and from this compa= ny may be monitored and recorded for legitimate purposes relating to this c= ompany's business. Any opinions expressed in this email (or in any atta= chments) are those of the author and do not necessarily represent the opini= ons of Moneyhub Financial Technology Limited or of any other group company.=





    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial= Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is a trading style= of Moneyhub Financial Technology Limited which is authorised and regulated= by the Financial Conduct Authority ("FCA").=C2=A0Moneyhub Financ= ial Technology is entered on the Financial Services Register=C2=A0(FRN=C2=A0809360<= span style=3D"font-size:0.75em">) at https://reg= ister.fca.org.uk/. M= oneyhub=C2=A0Financial Technology = is registered in England & Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0= =C2=A9

    DISCLAIMER: This = email (including any attachments) is subject to copyright, and the informat= ion in it is confidential. Use of this email or of any information in it ot= her than by the addressee is unauthorised and unlawful. Whilst reasonable e= fforts are made to ensure that any attachments are virus-free, it is the re= cipient's sole responsibility to scan all attachments for viruses. All = calls and emails to and from this company may be monitored and recorded for= legitimate purposes relating to this company's business. Any opinions = expressed in this email (or in any attachments) are those of the author and= do not necessarily represent the opinions of Moneyhub Financial Technology= Limited or of any other group company.

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

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


    --000000000000eab19605b68733be-- From nobody Tue Dec 15 15:02:14 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8F3A0800 for ; Tue, 15 Dec 2020 15:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTTdS1XOJzwM for ; Tue, 15 Dec 2020 15:02:05 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F6E3A07F5 for ; Tue, 15 Dec 2020 15:02:04 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id o19so18008536lfo.1 for ; Tue, 15 Dec 2020 15:02:04 -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=eKg902dKuaBc6lRE2sje5RiEgvJd8oGXeOa6ACO/wEY=; b=qwT7Yj2m5mq/u02TIqBgvasugYsUjWZli+HOTQTXxSenRpif9Q542Ak6/gMW56DL1S e+5zepy/NeMYnwcHWA2/q6FSP930pGhUlzIJLK0aUdZ8Fpk2Xp/JpT9Op2DYM630+a/h N2SVq/NDC92+4Cie4mcytOCnKfrrA6v8d8DoIWrJ/+jmWlQBXyLXsaU9NPjfK5mGPQX6 25FrcgFZGX1jLLrSrP3sRfv9/uD3fiIsgqqw8D65iVfLbv9I0FP6yhrXyoJ/7R3USotn gJVTp+1bGLt+0ECBlCC0j1YvTKihPd74kZwIlbD9GRcjJXEF/ifJ1ZFxKCKnrHAdQwbv yXXA== 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=eKg902dKuaBc6lRE2sje5RiEgvJd8oGXeOa6ACO/wEY=; b=QTbPYnG3iOal/nc1O8L6By7+6WBIUtVPWDhxR/aFyXPpxVwku9pOHMUe4kB7Xi/MTf JUS4wltKkGNt7LRHdEQVxOKhnBGyLQ/hxDtxOB40EZ0dU3l5IPM6vnEmhPkWGR3t2Seh jRap5umdvMnUenEZw7j9gDbjkYf1S0ROnEiU0dqiUmzZTNjBTWBjahvgc4TPLOIxXqkQ ZxOlAIluXNyeMKWKVPLoCq7a3y4y5xlCI3B+40jBpwSNwW1mdR6yITcY1UA/37GIIPw2 Z4NqjR7iOiFWnQ1tJ7MrksrKZg8ChRNxfI1sHrMy4jRK/2BD1QfYWSGGJqAqaA1awEy3 cT2g== X-Gm-Message-State: AOAM53367Ji60uoQogOrWpJFYGxOFelE5ABlu19N0iayAeGyB9kifkvw u3ok3BSPB9k+PbFRt62K1mNdnzI+FhPQu81eUBQ= X-Google-Smtp-Source: ABdhPJyrBgcCZIzfmqKECsv+ZzIAY3I3+/uYe2mPMhzXItQsSNrPcvGFsrjxFBOWQcYcX5F9c+OqJmLnhtppEBKnsUA= X-Received: by 2002:a19:38e:: with SMTP id 136mr9119691lfd.346.1608073321865; Tue, 15 Dec 2020 15:02:01 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 15 Dec 2020 15:01:50 -0800 Message-ID: To: Dave Tonge Cc: Fabien Imbault , Justin Richer , Steve Moore , Torsten Lodderstedt , txauth gnap Content-Type: multipart/alternative; boundary="0000000000001f66e005b688bf3e" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 23:02:13 -0000 --0000000000001f66e005b688bf3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dave: which points changed your mind? On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge wrote: > Thanks for the detailed response. > > I think you make the points well and I'm now in favour of the PR. > However I do think that to keep the consistency that keeps being > discussed, that the tokens shouldn't be rotated. > > I also think it would be good to have a discussion about "grant > management" and identifiers for a grant. > > Dave > > On Tue, 15 Dec 2020 at 17:30, Justin Richer wrote: > >> On Dec 15, 2020, at 10:50 AM, Dave Tonge wrote= : >> >> >> > The access token pattern has a lot of benefits, otherwise we wouldn=E2= =80=99t >> have an entire OAuth ecosystem based on it >> >> *But what are the benefits in this particular use case?* The >> continuation API is not like any other API - it is integral to the AS. >> There are quite a few extensions to OAuth that use client authentication >> rather than access tokens. >> >> >> Yes, and the propagation of that has lead to a mess in the OAuth world. >> You=E2=80=99ve got re-definitions of client authentications at all diffe= rent >> endpoints, they=E2=80=99re technically allowed to vary between endpoints= (though I >> don=E2=80=99t know of it happening in practice, that feels like a downgr= ade attack >> waiting to happen to someone). Then there=E2=80=99s the fact that all th= e newest >> security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 don= =E2=80=99t rely on client >> authentication at all to achieve security. All of these work without the >> client having credentials previously known to the AS, and we already kno= w >> that GNAP is going to need to live in this more dynamic world. We need t= o >> think beyond what OAuth 2 has done in the past, and especially from our >> perceptions and assumptions of the models that drive OAuth 2=E2=80=99s d= ecisions, >> lest we repeat its mistakes. >> >> Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2=80= =9D as a point. >> In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the server side, b= ut in OAuth 2 we >> split that into the RS concept. Even though in practice, a lot of RS=E2= =80=99s are >> still integrated to the AS in some fashion because it=E2=80=99s a single= service, >> OAuth 2 is clear about what=E2=80=99s expected to be known by each compo= nent. For >> the AS as currently defined in GNAP, I=E2=80=99m seeing three distinct f= unctions. >> As per the Terminology discussion, we don=E2=80=99t have explicit names = for these >> yet: >> >> - starting a request; this is an endpoint to kick things off; it needs >> to be able to look up the rights asked for by the client (if it knows th= e >> client at all ahead of time) and make initial decisions about needed >> interaction and follow up >> - continuing a request; this is an API that needs to know the context o= f >> the request itself, including which key it=E2=80=99s bound to; this is s= eparate >> from any identity of the client and possibly the user, but an AS >> implementation that has access to those elements can use them >> - interacting with the user; this is front-facing and in OAuth today is >> already deployed as a separate service in some places, we should embrace >> that at the very least (but doing so formally is a separate issue) >> >> Why separate these in this way? There is immense power in having a singl= e >> consistent way to start the process. The =E2=80=9Ccontinuation API=E2=80= =9D gives us an >> HTTP-defined mechanism for managing a request over time, including the >> simple case of returning information from the front channel, but people >> have already raised the question of non-HTTP and self-hosted AS=E2=80=99= s, which >> would probably want a different kind of continuation API to communicate = to >> the AS. The same thing with separating out the interaction: there are go= ing >> to be a lot of different ways to handle interaction out there, and not a= ll >> of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way that a s= imple >> implementation might do. We=E2=80=99re defining a protocol based strongl= y on HTTP >> and JSON, but we should structure it in such a way that it can be extend= ed >> and translated elsewhere in a clear way. >> >> This all raises the question: if we can rely on a unique URL for >> redirect-based interaction, why not here? The simple reason is that a UR= L >> is the :only: mechanism we have in the front channel for passing >> information, and we need to warn implementors against including sensitiv= e >> information in it, and we need to protect it with additional items. We h= ave >> access to more than just URLs when we=E2=80=99re dealing with the contin= uation API, >> and we ought to make use of all of our tools in ways that are consistent >> and make sense. >> >> From a previous email the advantages I see are: >> - more data can be encoded in a token than in a uri (this seems more of >> an edge case) >> - it can be an identifier for the grant (I don't agree with this) >> >> >> It allows the parts above to live separately, even if they don=E2=80=99t= HAVE to. >> And it simplifies what we=E2=80=99re asking the client to do by making i= t >> consistent with other parts of the ecosystem. The AS offering an API >> doesn=E2=80=99t :have: to be different, and OpenID Connect showed us, wi= th the >> UserInfo Endpoint, that that=E2=80=99s very much the case in practice. >> >> Having my client code do very similar things in slightly different ways >> is not simpler. >> >> >> Another question I have: *do we envisage granting access tokens to the >> RC that will allow it to manage multiple grants*? >> >> >> I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t be= en brought up as >> a use case to date. >> >> >> I also think there will be confusion with the signing being used for >> different things. Maybe it just needs to be called out in the spec that: >> >> Request 1: signature =3D client authentication >> Request 2+: signature =3D proof of possession for access token >> >> >> That=E2=80=99s more or less the intent of what=E2=80=99s in the specific= ation right now, >> and why all the signature methods, which are used for both client auth a= nd >> token possession, are all together in section 8 and not separated by use= . >> (With the caveat: it=E2=80=99s only client authentication in the first = request if >> the AS knows about the client instance ahead of time, which isn=E2=80=99= t always >> going to be true.) That all can likely be made clearer, as is always the >> case with spec text. But you can use the signature methods with and with= out >> access tokens, and it only gets used without in an initial call where yo= u >> don=E2=80=99t :have: an access token to present. >> >> Separating the different kinds of =E2=80=9Cclient authentication" out in= OAuth is >> the source of some real confusion. Like right now, what happens if you t= ry >> to combine a client assertion, signed request objects for PAR, and DPoP >> proofs, all in a single request? All of these are optional and all of th= em >> =E2=80=9Cdo client authentication=E2=80=9D in some arguable fashion. I= =E2=80=99ve worked on several >> systems and implemented these things, and their interplay is really >> confusing to manage and can go sideways really fast. And that=E2=80=99s = just the >> work for a single endpoint, this gets repeated for introspection, >> revocation, CIBA, device, and on. >> >> At the end of the day I=E2=80=99m in favor of giving the client develope= rs a very >> clear set of directions on what they need to do and how they need to acc= ess >> things, and treating the continuation as a token-bound API is, to me, th= e >> clearest pattern we can offer for this piece. >> >> =E2=80=94 Justin >> >> >> >> >> >> >> >> >> >> On Tue, 15 Dec 2020 at 15:33, Justin Richer wrote: >> >>> I agree with Fabien that the persistent identifier is a separate issue. >>> The current spec re-uses the access token for this artifact, but that= =E2=80=99s >>> potentially brittle and could be changed out for something else. There= =E2=80=99s an >>> issue asking for expanding on the use cases for this functionality (whi= ch >>> hasn=E2=80=99t been addressed by this PR): >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>> >>> A potentially-rotating URI would be just as brittle, and so having a >>> single codified identifier for this artifact would be useful, but it do= es >>> assume some things about the nature of the AS. Every other use the clie= nt >>> has to manage the ongoing request over time doesn=E2=80=99t need an exp= licit >>> identifier. Just like with OAuth-protected APIs, the server can determi= ne >>> the context not just from the URI but from the rest of the request, >>> including the access token itself. This is both more common and more >>> powerful than a strict reading of REST designs. It also follows the HAT= EOS >>> principles as the entire HTTP request is taken into account, including = the >>> access token and signature portions. >>> >>> I=E2=80=99ll also point out that the rotation of these credentials is a= lso filed >>> as a separate issue that=E2=80=99s not being addressed right now, so we= can revisit >>> that discussion separately: >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>> >>> As for the name, we could give it a different label. We have this same >>> pattern of issuing a resource-specific access token alongside a URL in = the >>> Dynamic Registration specification, both in OAuth ( >>> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( >>> https://openid.net/specs/openid-connect-registration-1_0.html#Registrat= ionResponse). >>> Here it=E2=80=99s called the =E2=80=9Cregistration access token=E2=80= =9D =E2=80=94 but what=E2=80=99s important >>> there, as it is here, is that it=E2=80=99s not a different kind of arti= fact that >>> the client now has to figure out how to use, it=E2=80=99s an access tok= en plain and >>> simple. In the OAuth world this is a bearer token, since that=E2=80=99s= what OAuth >>> 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2=80= =99s what we=E2=80=99re >>> looking to build on. This is also related to another future discussion >>> about responses tying an access token to a specific API that=E2=80=99s = told to the >>> client, as we could potentially re-use those components and concepts he= re >>> as well: >>> >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 >>> >>> And finally, no speculation on the complexity is needed: I implemented >>> this pattern several months ago during the design team discussions when= we >>> were considering this pattern, and the code is all online for people to >>> see. >>> >>> https://github.com/bspk/oauth.xyz-java/ >>> >>> On the AS side, the most interesting code to this discussion is in the >>> TransactionEndpoint class: >>> >>> >>> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/= bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java >>> >>> Here, you=E2=80=99ll see that on initial request, the server looks up t= he client >>> to see if it=E2=80=99s been registered, but after that, it makes sure t= hat the >>> token and key are appropriate for the ongoing request. From the client = side >>> it=E2=80=99s even simpler. The client=E2=80=99s got a small service fun= ction to manage the >>> different signature methods that are implemented, and all of them can t= ake >>> in an optional access token: >>> >>> >>> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/= bspk/oauth/xyz/http/SigningRestTemplateService.java >>> >>> The heavy lift is doing the actual signing, and you need that in order >>> to start the process anyway. Managing the access token as an artifact t= o >>> use at the API is completely trivial since the client already needs to >>> manage its own state internally to do any of this. And note that all of >>> this is changed from how it was before: Previously, the XYZ Protocol ha= d >>> used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the= client would use to >>> continue the request. However, this simple model was limiting, and the >>> design team adopted XAuth=E2=80=99s model of continuation being an API.= In doing >>> so, we made it like all of the other APIs the client is going to call: = in >>> the initial state, it doesn=E2=80=99t have any kind of access rights, i= t=E2=80=99s just >>> calling. From that initial call forward, the AS just needs to know that= the >>> token and key match what it expects. >>> >>> In summary, my views are: >>> - The access token pattern has a lot of benefits, otherwise we wouldn= =E2=80=99t >>> have an entire OAuth ecosystem based on it >>> - Magic URIs have a lot of drawbacks which are well understood; while >>> they can be mitigated, they can also be avoided >>> - Continuation is an API, and treating it like the other kinds of API >>> the client would call makes sense >>> - Calling this by a special name, like =E2=80=9Cgrant access token=E2= =80=9D or >>> =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should func= tion like any other >>> access token >>> - The heavy lift for clients is on protecting the message >>> cryptographically, which they need to do anyway >>> >>> =E2=80=94 Justin >>> >>> >>> On Dec 15, 2020, at 7:50 AM, Dave Tonge wrote= : >>> >>> The persistent identifier is not a different issue, the current access >>> token is used to reference an existing grant >>> >>> >>> >>> It may not be more difficult for a client to *use* an access token at >>> the AS / RS. But there is definitely an overhead on the client to >>> *manage* this separate access token. >>> >>> >>> >>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault >>> wrote: >>> >>>> I think we always said the access token was different, and handled as = a >>>> bound token. >>>> >>>> But it doesn't mean it's more difficult for the client that already >>>> needs to be able to handle tokens anyway (bearer or not, both cases co= uld >>>> occur). It's mostly consolidating the logic. >>>> >>>> You're anticipating a lot of issues which have no specific reason to >>>> occur, such as "can't be used with the token management APIs?". The >>>> management API is part of the same general flow. >>>> Anticipating issues with rotation is useful, but there are also many >>>> ways it can be hard to manage through a stateful approach too. And >>>> fundamentally, having everything in a common model (both for the inter= nals >>>> of the AS and for the API calls) will help improve by a large margin w= hat >>>> is probably the weakest point in today's infrastructure. But it's earl= y to >>>> be definitive as to the downstream impact either way. >>>> >>>> As for a persistent identifier instead of a continuation API, and >>>> generally the end of your message, it's a totally unrelated issue to t= his >>>> PR, so I suggest we don't discuss that here, but in a separate issue i= f >>>> needed. >>>> >>>> Fabien >>>> >>>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>>> wrote: >>>> >>>>> So we've established that this is a different access token, that >>>>> requires different handling at the client. So keeping it could cause = more >>>>> confusion? >>>>> >>>>> As an RC, I will have to store the continue `uri` as although it coul= d >>>>> be static it could also be dynamic. Why do I need to store an access = token >>>>> as well. It brings me no benefit as an RC, in fact it brings more >>>>> complexity. As I will now need to manage multiple types of tokens wit= h >>>>> different lifecycles: >>>>> >>>>> *Continuation token* >>>>> - can only be used at the continue endpoint (the name of which is >>>>> confusing as I can use this endpoint to revoke a grant or get metadat= a on >>>>> the grant). >>>>> - may be rotated each time it is used, or may not be >>>>> - provided in the `continue` section of the response >>>>> - must be sender-constrained >>>>> - can't be used with the token management APIs? >>>>> - can be used to identify the grant when making subsequent grants >>>>> >>>>> *Access token(s) to use at RS* >>>>> - can only be used at the specified RS >>>>> - may be sender constrained >>>>> - when used at the RS, will not result in rotation >>>>> >>>>> From my perspective, most use-cases will require the RC to have a >>>>> persistent identifier for the grant. Why not bring this into the prot= ocol >>>>> and let the AS provide this persistent identifier (through the form o= f the >>>>> continue uri). Using a rotating access token as a persistent identifi= er >>>>> doesn't seem like the right choice. >>>>> >>>>> I see no security benefit to having the continuation access token. It >>>>> doesn't matter if the continue uri leaks as it is useless without an >>>>> accompanying signature, i.e. any security benefit of having an access= token >>>>> is already provided by having a signature. >>>>> >>>>> The only benefits that I can see are: >>>>> - If the AS wants to be fully stateless, then you can encode more >>>>> data in a token than in a uri >>>>> - If the AS wants to have a static endpoint for CRUD operations on >>>>> the grant >>>>> - To allow the AS to identity a previous grant >>>>> >>>>> If we dropped the access token for the continue endpoint and rather >>>>> mandated a dynamic uri this would make things conceptually easier to >>>>> understand, easier for the RC to implement, easier to debug and less = chance >>>>> of errors when rotating tokens (i.e. race conditions could be quite l= ikely >>>>> if the AS always rotates the token) >>>>> >>>>> *One-off grant with no continuation or ongoing management:* >>>>> RC sends signature and metadata, no `continue` response provided, >>>>> therefore no grant management possible >>>>> >>>>> *Grant with ongoing management* >>>>> RC sends signature and metadata, AS responds with a continue uri that >>>>> has these purposes: >>>>> - can be used by the RC to continue/update, read or revoke the grant >>>>> - can be used by the RC when making a new grant to identify the >>>>> previous grant >>>>> >>>>> As an RC the only permanent items I need to store are: >>>>> - the continue uri associated with the grant >>>>> - any access tokens I receive for the grant >>>>> >>>>> Dave >>>>> >>>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >>>>> wrote: >>>>> >>>>>> Hi Torsten, >>>>>> >>>>>> You're right on both accounts. >>>>>> - for the first remark, it fits quite nicely the init request / >>>>>> continuation pattern >>>>>> - for the second remark, it is a sort of handle for the >>>>>> continuation request, which will eventually lead to the issuance or = refresh >>>>>> of standard access tokens >>>>>> >>>>>> Having a specific name is a possibility, I actually suggested that >>>>>> too at some point. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> wrote: >>>>>> >>>>>>> Hi Fabien, >>>>>>> >>>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>>> fabien.imbault@gmail.com>: >>>>>>> > >>>>>>> > Hi, >>>>>>> > >>>>>>> > On the contrary your feedback is most welcome. >>>>>>> > >>>>>>> > It doesn't accept any token, it needs the particular token as >>>>>>> described in 3.1 and which is not a bearer token (that's what the "= key" : >>>>>>> true parameter is supposed to convey). >>>>>>> > >>>>>>> > Let us know if you need more clarifications. >>>>>>> >>>>>>> Thanks for the clarification. I think only accepting this kind of >>>>>>> token at the continuation is a good idea otherwise the AS would nee= d to be >>>>>>> able to parse and understand all sorts of access tokens. >>>>>>> >>>>>>> Conceptually, I like the idea to treat the continuation as another >>>>>>> kind of resource. However, here are some observations I want to sha= re with >>>>>>> you: >>>>>>> - This resource is different as it will issue other access tokens >>>>>>> (of this kind) to be used in subsequent continuation requests. This >>>>>>> requires different handing on the client side. >>>>>>> - This access token (if I understand correctly) is (or at least >>>>>>> feels like) a handle for the underlying grant. So it is kind of the= super >>>>>>> access token to obtain other access tokens. >>>>>>> >>>>>>> I would consider using a different term to refer to this special >>>>>>> access token, grant token or grant handle for example, in order to = prevent >>>>>>> confusion. >>>>>>> >>>>>>> best regards, >>>>>>> Torsten. >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > Best >>>>>>> > Fabien >>>>>>> > >>>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>>> > Hi all, >>>>>>> > >>>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me questi= on seems >>>>>>> naive. >>>>>>> > >>>>>>> > After having skimmed through the current draft and the PR, I=E2= =80=98m not >>>>>>> sure whether the continuation requests accepts any access token iss= ued to >>>>>>> the RC or the particular access token returned in the =E2=80=9Econt= inue=E2=80=9C element in >>>>>>> section 3.1.. >>>>>>> > >>>>>>> > Can you please shed some light on this? >>>>>>> > >>>>>>> > kind regards, >>>>>>> > Torsten. >>>>>>> > >>>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>>> fabien.imbault@gmail.com>: >>>>>>> >> >>>>>>> >> =EF=BB=BF >>>>>>> >> You're completely right. Allowing the dev to be lazy is a very >>>>>>> good thing in general, because it's what we know will work :-) >>>>>>> >> >>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore >>>>>>> a =C3=A9crit : >>>>>>> >> Hi Fabien, >>>>>>> >> >>>>>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>>>>> sort of in the back of my mind, it isn't a huge risk there. So I ac= tually >>>>>>> agree with Dick there. Something doesn't sit right with me for the = unique >>>>>>> URL solution, so I don't like it and came up with a hypothetical th= at seems >>>>>>> like it could be a down side. >>>>>>> >> >>>>>>> >> I still think the access token model with the signed request is >>>>>>> the way I'd like to go, because again, it's a mechanism I'd be impl= ementing >>>>>>> anyway to talk to any 'normal' resource. The fact is there is _some= thing_ >>>>>>> representing context that has to pass back and forth here, whether = that is >>>>>>> an access token (which I feel like is more flexible for extensions = etc), a >>>>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy devel= oper ;) >>>>>>> >> -steve >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >> Again speaking in my own name here. >>>>>>> >> >>>>>>> >> Dick, we know you'd prefer to have a different design, but this >>>>>>> PR shouldn't be about that. >>>>>>> >> >>>>>>> >> Back on your 3 items : >>>>>>> >> >>>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>>> decided that wouldn't be how that would work. We have a client inst= ance >>>>>>> that allows a more generic and flexible pattern (which BTW also all= ows what >>>>>>> you want) >>>>>>> >> >>>>>>> >> 2) instead of blame arguments of who's less >>>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversatio= ns, I >>>>>>> suggest we speak in less abstract terms and ask ourselves what that= means >>>>>>> in practice for devs. Stephen and several others (myself included) = have >>>>>>> expressed that it wouldn't be harder to implement, it would even si= mplify >>>>>>> things quite a lot. If you disagree please send us a code sample to= really >>>>>>> show that point by example, because that's really not obvious. >>>>>>> >> >>>>>>> >> 3) "If someone has the client credentials, they can impersonate >>>>>>> the client, and all bets are off." Are you seriously making this ar= gument? >>>>>>> Because if you have a better proposal than using cryptographic keys= , I'm >>>>>>> all hears. You make it look like there's a problem, while in realit= y we're >>>>>>> only relying on the basic assumption of all modern digital communic= ations. >>>>>>> >> >>>>>>> >> And more importantly you never responded to the issues of how to >>>>>>> avoid the security pitfalls of what you proposed. >>>>>>> >> >>>>>>> >> Fabien >>>>>>> >> >>>>>>> >> >>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt >>>>>>> a =C3=A9crit : >>>>>>> >> >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>>>> wrote: >>>>>>> >> But from the spec: >>>>>>> >> " >>>>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>>>> identify itself by including the client field of the request... >>>>>>> >> ... >>>>>>> >> key (object / string) : The public key of the RC to be used in >>>>>>> this request as described in {{request-key}}. This field is REQUIRE= D. >>>>>>> >> ... >>>>>>> >> " >>>>>>> >> So on the initial request, the key will be there. >>>>>>> >> >>>>>>> >> The client field can be an object or a string. If the client is >>>>>>> pre-registered, then a string could be provided instead of an objec= t. >>>>>>> >> >>>>>>> >> >>>>>>> >> If you don't have the access token, then how do you differentiat= e >>>>>>> between two requests from the same web application by two different= users? >>>>>>> Is the web application supposed to have different credentials for e= very >>>>>>> request? >>>>>>> >> >>>>>>> >> The AS returns a URI for manipulating the request. I would chang= e >>>>>>> the spec so that each request would have a unique URI. This is the = usually >>>>>>> RESTful pattern that the resource (the grant request) has an URI. >>>>>>> >> >>>>>>> >> >>>>>>> >> So in this case, the easy way out is to pass the access token to >>>>>>> the client, who then, as i stated before, treats the continue reque= st as a >>>>>>> RS call (albeit a specialized version of the RS where the RS is the= AS) OR >>>>>>> to use the unique URL, >>>>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>>>> (What would be the point of that attack, I don't know, I guess if s= omeone >>>>>>> had the client credentials but not any subjects/resources they coul= d try to >>>>>>> intercept the grant via continue... I just don't feel right locking= things >>>>>>> down to unique URLs that way.) >>>>>>> >> >>>>>>> >> If someone has the client credentials, they can impersonate the >>>>>>> client, and all bets are off. >>>>>>> >> >>>>>>> >> LOTS of RS servers return a resource specific URL -- my proposal >>>>>>> is no different. >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> -steve >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>>>> wrote: >>>>>>> >> Hi Stephen >>>>>>> >> >>>>>>> >> The client is signing the first request. The key *might* be in >>>>>>> the body. The client is signing all the subsequent requests as well= . The >>>>>>> "access token" is not needed by the client to prove it is authorize= d as the >>>>>>> client is proving it is the same client again. >>>>>>> >> >>>>>>> >> In other words, I don't see the need for an access token, so it >>>>>>> does not need to be put in a URL or an auth header. >>>>>>> >> >>>>>>> >> If a developer really, really wants to hand context back to the >>>>>>> client for subsequent calls, they can put it in the URL or some oth= er >>>>>>> method. Putting it in the HTTP Authorization header is confusing be= cause it >>>>>>> is NOT an access token -- it is the context of the request. >>>>>>> >> >>>>>>> >> =E1=90=A7 >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>>>> wrote: >>>>>>> >> Even though I've only been lightly following things, I feel the >>>>>>> need to voice my preference as a developer since I will probably so= meday >>>>>>> have to either write a RC or RS... >>>>>>> >> >>>>>>> >> The way I see it is the RC makes the initial request to the AS a= s >>>>>>> part of this request, it provides it's key in the body... (So no us= e of the >>>>>>> Authorization header) >>>>>>> >> At this point that request, represented by the continue URL + >>>>>>> "Access Token", from my lazy developer standpoint, is a Resource En= dpoint >>>>>>> and Access Token, and the AS is acting as a specialized RS in this = case. >>>>>>> >> So my client posts to whatever URL with the 'access token' in th= e >>>>>>> authorization header, just like acting on any other resource I have= a token >>>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>>> decision point of "Do I have another continue, or do I have a real = token >>>>>>> for the resource..." But the mechanism is the same to me in the cli= ent. >>>>>>> >> Personally I like that, because if I have an access_token, I >>>>>>> already think "Put it in the auth header." >>>>>>> >> >>>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>>> >> -steve >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>>> wrote: >>>>>>> >> inline ... >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>> wrote: >>>>>>> >> Others had already responded to this previous thread, but I >>>>>>> wanted to add a couple points to clarify some things. >>>>>>> >> >>>>>>> >>> 3) What the client has to do with the "access token" is not the >>>>>>> same as access tokens for an RS. The client gets a new "access toke= n" for >>>>>>> each grant request, and for each API call to the AS, and the client= learns >>>>>>> it can not make any more API calls for that specific request when i= t does >>>>>>> not get an "access token" back. This is a completely different desi= gn >>>>>>> pattern than calling an RS API with an access token, and is a new d= esign >>>>>>> pattern for calling APIs. This adds complexity to the client that i= t would >>>>>>> not normally have, and I don't think GNAP is the right place to sta= rt a new >>>>>>> design pattern. >>>>>>> >>> >>>>>>> >> >>>>>>> >> I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole >>>>>>> point of the design is that the client would be doing the same thin= g with >>>>>>> the access token at the AS that it does with the RS by re-using the= access >>>>>>> token structure. Can you please describe what the differences are, = apart >>>>>>> from the rotation? Presentation of the token and signing of the mes= sage are >>>>>>> identical. >>>>>>> >> >>>>>>> >> The client is getting the "access token" from its API. It is not >>>>>>> using an "access_token" in other API calls to the AS. >>>>>>> >> >>>>>>> >> >>>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>>> continuation responses is a separate issue to be discussed: >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>> >> >>>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right pl= ace to >>>>>>> have new designs =E2=80=94 not that this is one. >>>>>>> >> >>>>>>> >> You are proposing a new way for an API to provide context for >>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>> >> >>>>>>> >> >>>>>>> >>> 4) Clients that only want claims from the AS and no access >>>>>>> tokens will be required to support an API calling mechanism they wo= uld not >>>>>>> have to support otherwise. >>>>>>> >> >>>>>>> >> Correct, but the delta between the calls a client would make wit= h >>>>>>> and without an access token is vanishingly small. The client has to= sign >>>>>>> the initial request in some fashion, and it will sign the continuat= ion >>>>>>> request in the same exact fashion, but now include an access token = in that >>>>>>> request. >>>>>>> >> >>>>>>> >> Per my other point, there is no value to me in my implementation= s >>>>>>> of passing context back and forth between the client and AS -- so i= t is >>>>>>> extra work providing no value. >>>>>>> >> >>>>>>> >> Also, any client authentication mechanism that wants to use the >>>>>>> HTTP Authentication header is precluded from using it. >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> Clients making a request to an AS and not getting an access toke= n >>>>>>> is a new design pattern. I think it has value and should be include= d, but >>>>>>> OAuth today shows us the immense value of getting access tokens for= calling >>>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>>> >> >>>>>>> >>> >>>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>>> mechanism for a client to delete the request, as the client is not = allowed >>>>>>> to make a call without an "access token". >>>>>>> >> >>>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>>>> is telling this client instance that it can=E2=80=99t do anything e= lse with this >>>>>>> ongoing request. If the AS wants to allow the client to manage it, = it will >>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D f= ield. >>>>>>> >> >>>>>>> >> There is nuance in that intention. A related concern is that >>>>>>> deleting a request does not seem like it is a "continue" operation. >>>>>>> >> >>>>>>> >> >>>>>>> >>> >>>>>>> >>> 6) There is no standard identifier for the request. Debugging >>>>>>> and auditing are hampered by the client and AS having no standard w= ay to >>>>>>> identifying a request. While one AS may provide a unique URL for ea= ch grant >>>>>>> request, another AS may use a persistent "access token" to identify= the >>>>>>> grant request, and other ASs may issue a new "access token" on each= API >>>>>>> call, providing no persistent identifier for the request. >>>>>>> >> >>>>>>> >> Debugging and auditing this kind of thing are functions of the >>>>>>> AS. How is interoperability harmed by different ASs having differen= t >>>>>>> methods to identify their internal data elements? The client doesn= =E2=80=99t need >>>>>>> any knowledge of the AS=E2=80=99s identifiers, it just needs to kno= w the next steps >>>>>>> for continuing the negotiation. >>>>>>> >> >>>>>>> >> Debugging between the client and the AS was what I was referring >>>>>>> to. How does a client developer identify the request when communica= ting to >>>>>>> the AS developer. Seems complicated. >>>>>>> >> >>>>>>> >> =E1=90=A7 >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >> =E1=90=A7 >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> >>>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinf= o/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu= 0IQPJJYtSpI >>>>>>> >>>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Tonge >>>>> CTO >>>>> [image: Moneyhub Enterprise] >>>>> >>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>> BS1 6FL >>>>> >>>>> t: +44 (0)117 280 5120 >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at *https://register.fca.org= .uk/ >>>>> *. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772 = . >>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at >>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772. >>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise= , Regus >>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>> >>>>> . >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> >>> >>> -- >>> Dave Tonge >>> CTO >>> [image: Moneyhub Enterprise] >>> >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>> 6FL >>> >>> t: +44 (0)117 280 5120 >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at *https://register.fca.org.u= k/ >>> *. Moneyhub Financial Technology is >>> registered in England & Wales, company registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, >>> BS1 6EA >>> >>> . >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >> 6FL >> >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA >> >> . >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> >> > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA > > . > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > --0000000000001f66e005b688bf3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dave: which points changed your mind?

    On Tue, Dec 15,= 2020 at 1:11 PM Dave Tonge <= dave.tonge@moneyhub.com> wrote:
    Thanks for the detailed response.
    I think you make the points well and I'm now in favo= ur of the PR.
    However I do think that to keep the consiste= ncy that keeps being discussed, that the tokens shouldn't be rotated.= =C2=A0

    I also think it would be good= to have a discussion about "grant management" and identifiers fo= r a grant.

    On Tue, 15 Dec 2020 at 17:30, Justin Richer <jricher@mit.edu> wrote:
    On Dec 15, 2020, at 10:50 AM, Dave Tonge <dave.tonge@moneyhub= .com> wrote:

    >=C2=A0The access token pattern has a lot of benefits, otherwise we wouldn= =E2=80=99t have an entire OAuth ecosystem based on it

    =
    But what are the benefits=C2=A0in this part= icular use case? The continuation API is not like any other API - it is= integral to the AS. There are quite a few extensions to OAuth that use cli= ent authentication rather than access tokens.

    Yes, and the propagation of that has lead to a mess in= the OAuth world. You=E2=80=99ve got re-definitions of client authenticatio= ns at all different endpoints, they=E2=80=99re technically allowed to vary = between endpoints (though I don=E2=80=99t know of it happening in practice,= that feels like a downgrade attack waiting to happen to someone). Then the= re=E2=80=99s the fact that all the newest security mechanisms we have =E2= =80=94 PKCE, DPoP, and MTLS =E2=80=94 don=E2=80=99t rely on client authenti= cation at all to achieve security. All of these work without the client hav= ing credentials previously known to the AS, and we already know that GNAP i= s going to need to live in this more dynamic world. We need to think beyond= what OAuth 2 has done in the past, and especially from our perceptions and= assumptions of the models that drive OAuth 2=E2=80=99s decisions, lest we = repeat its mistakes.=C2=A0

    Also, I want to challen= ge this idea of =E2=80=9Cintegral to the AS=E2=80=9D as a point. In OAuth 1= , the API was =E2=80=9Cintegral=E2=80=9D to the server side, but in OAuth 2= we split that into the RS concept. Even though in practice, a lot of RS=E2= =80=99s are still integrated to the AS in some fashion because it=E2=80=99s= a single service, OAuth 2 is clear about what=E2=80=99s expected to be kno= wn by each component. For the AS as currently defined in GNAP, I=E2=80=99m = seeing three distinct functions. As per the Terminology discussion, we don= =E2=80=99t have explicit names for these yet:

    =C2= =A0- starting a request; this is an endpoint to kick things off; it needs t= o be able to look up the rights asked for by the client (if it knows the cl= ient at all ahead of time) and make initial decisions about needed interact= ion and follow up
    =C2=A0- continuing a request; this is an API that ne= eds to know the context of the request itself, including which key it=E2=80= =99s bound to; this is separate from any identity of the client and possibl= y the user, but an AS implementation that has access to those elements can = use them
    =C2=A0- interacting with the user; this is front-facing = and in OAuth today is already deployed as a separate service in some places= , we should embrace that at the very least (but doing so formally is a sepa= rate issue)

    Why separate these in this way? There = is immense power in having a single consistent way to start the process. Th= e =E2=80=9Ccontinuation API=E2=80=9D gives us an HTTP-defined mechanism for= managing a request over time, including the simple case of returning infor= mation from the front channel, but people have already raised the question = of non-HTTP and self-hosted AS=E2=80=99s, which would probably want a diffe= rent kind of continuation API to communicate to the AS. The same thing with= separating out the interaction: there are going to be a lot of different w= ays to handle interaction out there, and not all of them will be =E2=80=9Ci= ntegral=E2=80=9D to the AS in the way that a simple implementation might do= . We=E2=80=99re defining a protocol based strongly on HTTP and JSON, but we= should structure it in such a way that it can be extended and translated e= lsewhere in a clear way.

    This all raises the question: if we = can rely on a unique URL for redirect-based interaction, why not here? The = simple reason is that a URL is the :only: mechanism we have in the front ch= annel for passing information, and we need to warn implementors against inc= luding sensitive information in it, and we need to protect it with addition= al items. We have access to more than just URLs when we=E2=80=99re dealing = with the continuation API, and we ought to make use of all of our tools in = ways that are consistent and make sense.

    From a = previous email the advantages I see are:
    = =C2=A0- more data can be encoded in a token than in a uri (this seems more = of an edge case)
    =C2=A0- it can be an ide= ntifier for the grant (I don't agree with this)

    It allows the parts above to live separately, ev= en if they don=E2=80=99t HAVE to. And it simplifies what we=E2=80=99re aski= ng the client to do by making it consistent with other parts of the ecosyst= em. The AS offering an API doesn=E2=80=99t :have: to be different, and Open= ID Connect showed us, with the UserInfo Endpoint, that that=E2=80=99s very = much the case in practice.=C2=A0

    Having my client = code do very similar things in slightly different ways is not simpler.

    Another question I have: d= o we envisage granting access tokens to the RC that will allow it to manage= multiple grants?=C2=A0=C2=A0

    I don=E2=80=99t see that happening, personally, and it hasn=E2=80= =99t been brought up as a use case to date.=C2=A0


    I also think there will be confusion with the sign= ing being used for different things. Maybe it just needs to be called out i= n the spec that:

    Request 1: signature =3D client authentication
    Request 2+: signature =3D proof of possession for = access token


    That=E2=80=99s more or less the intent of what= =E2=80=99s in the specification right now, and why all the signature method= s, which are used for both client auth and token possession, are all togeth= er in section 8 and not separated by use. =C2=A0(With the caveat: it=E2=80= =99s only client authentication in the first request if the AS knows about = the client instance ahead of time, which isn=E2=80=99t always going to be t= rue.) That all can likely be made clearer, as is always the case with spec = text. But you can use the signature methods with and without access tokens,= and it only gets used without in an initial call where you don=E2=80=99t := have: an access token to present.

    Separating the d= ifferent kinds of =E2=80=9Cclient authentication" out in OAuth is the = source of some real confusion. Like right now, what happens if you try to c= ombine a client assertion, signed request objects for PAR, and DPoP proofs,= all in a single request? All of these are optional and all of them =E2=80= =9Cdo client authentication=E2=80=9D in some arguable fashion. I=E2=80=99ve= worked on several systems and implemented these things, and their interpla= y is really confusing to manage and can go sideways really fast. And that= =E2=80=99s just the work for a single endpoint, this gets repeated for intr= ospection, revocation, CIBA, device, and on.

    At th= e end of the day I=E2=80=99m in favor of giving the client developers a ver= y clear set of directions on what they need to do and how they need to acce= ss things, and treating the continuation as a token-bound API is, to me, th= e clearest pattern we can offer for this piece.

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








    On Tue, 15 Dec 2020 at 15:33, Justin Richer <jricher@mit.edu> wr= ote:
    I agree with Fabien that the persistent= identifier is a separate issue. The current spec re-uses the access token = for this artifact, but that=E2=80=99s potentially brittle and could be chan= ged out for something else. There=E2=80=99s an issue asking for expanding o= n the use cases for this functionality (which hasn=E2=80=99t been addressed= by this PR):


    A potentially-rot= ating URI would be just as brittle, and so having a single codified identif= ier for this artifact would be useful, but it does assume some things about= the nature of the AS. Every other use the client has to manage the ongoing= request over time doesn=E2=80=99t need an explicit identifier. Just like w= ith OAuth-protected APIs, the server can determine the context not just fro= m the URI but from the rest of the request, including the access token itse= lf. This is both more common and more powerful than a strict reading of RES= T designs. It also follows the HATEOS principles as the entire HTTP request= is taken into account, including the access token and signature portions.= =C2=A0

    I=E2=80=99ll also point out that the rotati= on of these credentials is also filed as a separate issue that=E2=80=99s no= t being addressed right now, so we can revisit that discussion separately:<= div>

    As for the name, we could= give it a different label. We have this same pattern of issuing a resource= -specific access token alongside a URL in the Dynamic Registration specific= ation, both in OAuth (https://tools.ietf.org/html/rfc7592#section-3) a= nd OpenID Connect (https://openid.net= /specs/openid-connect-registration-1_0.html#RegistrationResponse). Here= it=E2=80=99s called the =E2=80=9Cregistration access token=E2=80=9D =E2=80= =94 but what=E2=80=99s important there, as it is here, is that it=E2=80=99s= not a different kind of artifact that the client now has to figure out how= to use, it=E2=80=99s an access token plain and simple. In the OAuth world = this is a bearer token, since that=E2=80=99s what OAuth 2 uses. In the GNAP= world it=E2=80=99ll be a bound token, as that=E2=80=99s what we=E2=80=99re= looking to build on. This is also related to another future discussion abo= ut responses tying an access token to a specific API that=E2=80=99s told to= the client, as we could potentially re-use those components and concepts h= ere as well:


    And fi= nally, no speculation on the complexity is needed: I implemented this patte= rn several months ago during the design team discussions when we were consi= dering this pattern, and the code is all online for people to see.=C2=A0

    On the AS side, the most interesting code to this discussion is= in the TransactionEndpoint class:


    Here, you=E2=80=99ll see that on initial request, the server looks up= the client to see if it=E2=80=99s been registered, but after that, it make= s sure that the token and key are appropriate for the ongoing request. From= the client side it=E2=80=99s even simpler. The client=E2=80=99s got a smal= l service function to manage the different signature methods that are imple= mented, and all of them can take in an optional access token:=C2=A0

    https://github.com/bspk/oauth.xyz-java/blob/master/rc/= src/main/java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java

    The heavy lift is doing the actual signing, and you = need that in order to start the process anyway. Managing the access token a= s an artifact to use at the API is completely trivial since the client alre= ady needs to manage its own state internally to do any of this. And note th= at all of this is changed from how it was before: Previously, the XYZ Proto= col had used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that= the client would use to continue the request. However, this simple model w= as limiting, and the design team adopted XAuth=E2=80=99s model of continuat= ion being an API. In doing so, we made it like all of the other APIs the cl= ient is going to call: in the initial state, it doesn=E2=80=99t have any ki= nd of access rights, it=E2=80=99s just calling. From that initial call forw= ard, the AS just needs to know that the token and key match what it expects= .=C2=A0

    In summary, my views are:
    =C2=A0= - The access token pattern has a lot of benefits, otherwise we wouldn=E2=80= =99t have an entire OAuth ecosystem based on it
    =C2=A0- Magic URI= s have a lot of drawbacks which are well understood; while they can be miti= gated, they can also be avoided
    =C2=A0- Continuation is an API, a= nd treating it like the other kinds of API the client would call makes sens= e
    =C2=A0- Calling this by a special name, like =E2=80=9Cgrant acc= ess token=E2=80=9D or =E2=80=9Ccontinuation access token=E2=80=9D is fine, = but it should function like any other access token
    =C2=A0- The he= avy lift for clients is on protecting the message cryptographically, which = they need to do anyway

    =C2=A0=E2=80=94 Justin


    On Dec 15, 2020, at 7:50 = AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    =
    The persistent identifier=C2=A0is not a different issue, the cu= rrent access token is used to reference an existing grant= =C2=A0

    It may not be more difficult = for a client to manage=C2=A0this separate access token.=C2=A0



    On Tue, 15 Dec 2020 at 12:10, Fabien Imb= ault <fabi= en.imbault@gmail.com> wrote:
    I think we always said the access token was different, and handled as a= bound token.

    But it doesn't mean it's more diff= icult for the client that already needs to be able to handle tokens anyway = (bearer or not, both cases could occur). It's mostly consolidating the = logic.

    You're anticipating a lot of issue= s which have no specific reason to occur, such as "can't be used with the tok= en management APIs?". The management API is part of the same general f= low.
    Anticipating issues with rotation is useful, but there are also = many ways it can be hard to manage through a stateful approach too. And fun= damentally, having everything in a common model (both for the internals of = the AS and for the API calls) will help improve by a large margin what is p= robably the weakest point in today's infrastructure. But it's early= to be definitive as to the downstream impact either way.=C2=A0 =C2=A0

    As for a persistent identifier instead of a continuation A= PI, and generally the end of your message, it's a totally unrelated iss= ue to this PR, so I suggest we don't discuss that here, but in a separa= te issue if needed.

    Fabien

    On Tu= e, Dec 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established th= at this is a different access token, that requires different handling at th= e client. So keeping it could cause more confusion?

    As an RC, I will have to store the continue `uri` as althou= gh it could be static it could also be dynamic. Why do I need to store an a= ccess token as well.=C2=A0It brings me no benefit as an RC, in fact it brin= gs more complexity. As I will now need to manage multiple types of tokens w= ith different lifecycles:

    Continuation token= =C2=A0
    =C2=A0 - can only be used at the continue endpoint = (the name of which is confusing as I can use this endpoint to revoke a gran= t or get metadata on the grant).
    =C2=A0- may be rotated ea= ch time it is used, or may not be
    =C2=A0- provided in th= e `continue` section of the response
    =C2=A0- must be sende= r-constrained
    =C2=A0- can't be used with the token man= agement APIs?
    =C2=A0- can be used to identify the grant wh= en making subsequent grants

    Access token(s) to use= at RS
    =C2=A0=C2=A0- can only be used at the specified RS
    <= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif">=C2=A0 - may be sender constrained
    =C2=A0 - whe= n used at the RS, will not result in rotation

    From my perspective, most use-cases will require the RC to have a= persistent identifier for the grant. Why not bring this into the protocol = and let the AS provide this persistent identifier (through the form of the = continue uri). Using a rotating access token as a persistent identifier doe= sn't seem like the right choice.=C2=A0

    I see no security benefit to having the continuation access token. I= t doesn't matter if the continue uri leaks as it is useless without an = accompanying signature, i.e. any security benefit of having an access token= is already provided by having a signature.

    The only benefits that I can see are:
    =C2=A0- If t= he AS wants to be fully stateless, then you can encode more data in a token= than in a uri
    =C2=A0- If the AS wants to have a static en= dpoint for CRUD operations on the grant
    =C2=A0- To allow t= he AS to identity a previous grant


    One-off grant with no = continuation or ongoing management:
    RC sends signature= and metadata, no `continue` response provided, therefore no grant manageme= nt possible

    Grant with ongoing management
    RC sends signature and metadata, AS responds with a continue= uri that has these purposes:
    =C2=A0- can be used by the R= C to continue/update, read or revoke the grant
    =C2=A0- can= be used by the RC when making a new grant to identify the previous grant

    As an RC the only permanent items I n= eed to store are:
    =C2=A0- the continue uri associated with= the grant
    =C2=A0- any access tokens I receive for the gra= nt

    Dave

    On Tue, 15 Dec 2020 at = 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Torsten,=C2=A0

    You're right = on both accounts.=C2=A0
    - for the first remark, it fits quite nic= ely the init request=C2=A0 / continuation pattern=C2=A0
    - for the= second remark, it is a sort of handle for the continuation=C2=A0request, w= hich will eventually lead to the issuance or refresh of standard access tok= ens=C2=A0

    Having a specific=C2=A0name is a possibi= lity, I actually suggested that too at some point.=C2=A0

    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <= torsten@lodder= stedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th Floor, 10 = Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120
    Moneyhub Enterprise is a trading style of M= oneyhub Financial Technology Limited which is authorised and regulated by t= he Financial Conduct Authority ("FCA").=C2=A0Moneyhub Financial T= echnology is entered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://re= gister.fca.org.uk/. Mo= neyhub=C2=A0Financial Technology is registered in England = & Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email (including any attachments) is subject to c= opyright, and the information in it is confidential. Use of this email or o= f any information in it other than by the addressee is unauthorised and unl= awful. Whilst reasonable efforts are made to ensure that any attachments ar= e virus-free, it is the recipient's sole responsibility to scan all att= achments for viruses. All calls and emails to and from this company may be = monitored and recorded for legitimate purposes relating to this company'= ;s business. Any opinions expressed in this email (or in any attachments) a= re those of the author and do not necessarily represent the opinions of Mon= eyhub Financial Technology Limited or of any other group company.

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Br= istol, BS1 6EA.=C2=A0

    DISCLA= IMER: This email (including any attachments) is subject to copyright, and t= he information in it is confidential. Use of this email or of any informati= on in it other than by the addressee is unauthorised and unlawful. Whilst r= easonable efforts are made to ensure that any attachments are virus-free, i= t is the recipient's sole responsibility to scan all attachments for vi= ruses. All calls and emails to and from this company may be monitored and r= ecorded for legitimate purposes relating to this company's business. An= y opinions expressed in this email (or in any attachments) are those of the= author and do not necessarily represent the opinions of Moneyhub Financial= Technology Limited or of any other group company.




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th Floor, 10 = Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120
    Moneyhub Enterprise is a trading style of M= oneyhub Financial Technology Limited which is authorised and regulated by t= he Financial Conduct Authority ("FCA").=C2=A0Moneyhub Financial T= echnology is entered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://re= gister.fca.org.uk/. Mo= neyhub=C2=A0Financial Technology is registered in England = & Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email (including any attachments) is subject to c= opyright, and the information in it is confidential. Use of this email or o= f any information in it other than by the addressee is unauthorised and unl= awful. Whilst reasonable efforts are made to ensure that any attachments ar= e virus-free, it is the recipient's sole responsibility to scan all att= achments for viruses. All calls and emails to and from this company may be = monitored and recorded for legitimate purposes relating to this company'= ;s business. Any opinions expressed in this email (or in any attachments) a= re those of the author and do not necessarily represent the opinions of Mon= eyhub Financial Technology Limited or of any other group company.

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Br= istol, BS1 6EA.=C2=A0

    DISCLA= IMER: This email (including any attachments) is subject to copyright, and t= he information in it is confidential. Use of this email or of any informati= on in it other than by the addressee is unauthorised and unlawful. Whilst r= easonable efforts are made to ensure that any attachments are virus-free, i= t is the recipient's sole responsibility to scan all attachments for vi= ruses. All calls and emails to and from this company may be monitored and r= ecorded for legitimate purposes relating to this company's business. An= y opinions expressed in this email (or in any attachments) are those of the= author and do not necessarily represent the opinions of Moneyhub Financial= Technology Limited or of any other group company.



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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th Floor, 10 = Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120
    Moneyhub Enterprise is a trading style of M= oneyhub Financial Technology Limited which is authorised and regulated by t= he Financial Conduct Authority ("FCA").=C2=A0Moneyhub Financial T= echnology is entered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://re= gister.fca.org.uk/. Mo= neyhub=C2=A0Financial Technology is registered in England = & Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email (including any attachments) is subject to c= opyright, and the information in it is confidential. Use of this email or o= f any information in it other than by the addressee is unauthorised and unl= awful. Whilst reasonable efforts are made to ensure that any attachments ar= e virus-free, it is the recipient's sole responsibility to scan all att= achments for viruses. All calls and emails to and from this company may be = monitored and recorded for legitimate purposes relating to this company'= ;s business. Any opinions expressed in this email (or in any attachments) a= re those of the author and do not necessarily represent the opinions of Mon= eyhub Financial Technology Limited or of any other group company.

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Br= istol, BS1 6EA.=C2=A0

    DISCLA= IMER: This email (including any attachments) is subject to copyright, and t= he information in it is confidential. Use of this email or of any informati= on in it other than by the addressee is unauthorised and unlawful. Whilst r= easonable efforts are made to ensure that any attachments are virus-free, i= t is the recipient's sole responsibility to scan all attachments for vi= ruses. All calls and emails to and from this company may be monitored and r= ecorded for legitimate purposes relating to this company's business. An= y opinions expressed in this email (or in any attachments) are those of the= author and do not necessarily represent the opinions of Moneyhub Financial= Technology Limited or of any other group company.




    <= br>
    --
    Dave Tonge
    CTO
    3D"Moneyhub
    <= div style=3D"font-family:lato,"open sans",arial,sans-serif;font-s= ize:14px;letter-spacing:normal;line-height:normal;color:rgb(51,51,51)">
    Moneyhub Ent= erprise is a trading style of Moneyhub Financial Technology Limited which i= s authorised and regulated by the Financial Conduct Authority ("FCA&qu= ot;).=C2=A0Moneyhub Financial Technology is entered on the Financial Servic= es Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/. M<= /span>oneyhub=C2=A0Financial Techn= ology is registered in England & Wales, company registration number=C2= =A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited= 2019=C2=A0=C2=A9
    <= div style=3D"font-family:lato,"open sans",arial,sans-serif;font-s= ize:14px;letter-spacing:normal;line-height:1.4;color:rgb(51,51,51)">
    DISCLAIMER: This email (including any= attachments) is subject to copyright, and the information in it is confide= ntial. Use of this email or of any information in it other than by the addr= essee is unauthorised and unlawful. Whilst reasonable efforts are made to e= nsure that any attachments are virus-free, it is the recipient's sole r= esponsibility to scan all attachments for viruses. All calls and emails to = and from this company may be monitored and recorded for legitimate purposes= relating to this company's business. Any opinions expressed in this em= ail (or in any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of any o= ther group company.
    <= /div>

    Moneyhub Enterprise is a = trading style of Moneyhub Financial Technology Limited which is authorised = and regulated by the Financial Conduct Authority ("FCA"). Moneyhu= b Financial Technology is entered on the Financial Services Register (FRN 8= 09360) at https://register.f= ca.org.uk/. Moneyhub Financial Technology is registered in Engla= nd & Wales, company registration number 06909772. Moneyhub Financial Te= chnology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Qu= ay, 1 Friary, Brist= ol, BS1 6EA.=C2=A0

    = DISCLAIME= R: This email (including any attachments) is subject to copyright, and the = information in it is confidential. Use of this email or of any information = in it other than by the addressee is unauthorised and unlawful. Whilst reas= onable efforts are made to ensure that any attachments are virus-free, it i= s the recipient's sole responsibility to scan all attachments for virus= es. All calls and emails to and from this company may be monitored and reco= rded for legitimate purposes relating to this company's business. Any o= pinions expressed in this email (or in any attachments) are those of the au= thor and do not necessarily represent the opinions of Moneyhub Financial Te= chnology Limited or of any other group company.


    --0000000000001f66e005b688bf3e-- From nobody Tue Dec 15 17:15:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEB43A0A9C for ; Tue, 15 Dec 2020 17:14:58 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_oIzFjOD4mF for ; Tue, 15 Dec 2020 17:14:54 -0800 (PST) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 DA0C23A0A94 for ; Tue, 15 Dec 2020 17:14:53 -0800 (PST) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 0BG1Ef7G013294; Tue, 15 Dec 2020 20:14:47 -0500 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 15 Dec 2020 20:14:38 -0500 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 15 Dec 2020 20:14:43 -0500 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 15 Dec 2020 20:14:43 -0500 From: Justin Richer To: Dave Tonge CC: Fabien Imbault , Torsten Lodderstedt , txauth gnap , Steve Moore , Dick Hardt Thread-Topic: [GNAP] Consensus Call on Continuation Request Thread-Index: AQHWzwxm6uRlbDql0kaDEIWoUgIODKnxFToAgAEbKwCAAHZ9gIAAIT4AgAAIowCAAAW2gIAAC4GAgAAmYYCAAAacAIAABYUAgACFqgCAAAkwgIAEkQaAgAAFwQCAABAZgIAAETcAgAAb5wD//8kQAIAAaXeA//+3RICAAKJDgP//78pd Date: Wed, 16 Dec 2020 01:14:43 +0000 Message-ID: <8b3d50ca154a42718cf76a3d36a8e2c5@oc11expo18.exchange.mit.edu> References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [71.174.62.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 16 Dec 2020 01:14:59 -0000 SSdtIGluIGFncmVlbWVudCB3aXRoIHRoZSBuZWVkIGZvciBib3RoIG9mIHRob3NlIGRpc2N1c3Np b25zLCB3ZSd2ZSBhIHdheXMgdG8gZ28gZm9yIHRoaXMgcHJvdG9jb2wsIHlldC4gVGhhbmtzIGZv ciB0aGUgZGlzY3Vzc2lvbiBhbmQgaW5zaWdodHMuIA0KDQotIEp1c3Rpbg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogRGF2ZSBUb25nZSBbZGF2ZS50b25n ZUBtb25leWh1Yi5jb21dDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwgMjAyMCA0OjExIFBN DQpUbzogSnVzdGluIFJpY2hlcg0KQ2M6IEZhYmllbiBJbWJhdWx0OyBUb3JzdGVuIExvZGRlcnN0 ZWR0OyB0eGF1dGggZ25hcDsgU3RldmUgTW9vcmU7IERpY2sgSGFyZHQNClN1YmplY3Q6IFJlOiBb R05BUF0gQ29uc2Vuc3VzIENhbGwgb24gQ29udGludWF0aW9uIFJlcXVlc3QNCg0KVGhhbmtzIGZv ciB0aGUgZGV0YWlsZWQgcmVzcG9uc2UuDQoNCkkgdGhpbmsgeW91IG1ha2UgdGhlIHBvaW50cyB3 ZWxsIGFuZCBJJ20gbm93IGluIGZhdm91ciBvZiB0aGUgUFIuDQpIb3dldmVyIEkgZG8gdGhpbmsg dGhhdCB0byBrZWVwIHRoZSBjb25zaXN0ZW5jeSB0aGF0IGtlZXBzIGJlaW5nIGRpc2N1c3NlZCwg dGhhdCB0aGUgdG9rZW5zIHNob3VsZG4ndCBiZSByb3RhdGVkLg0KDQpJIGFsc28gdGhpbmsgaXQg d291bGQgYmUgZ29vZCB0byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCAiZ3JhbnQgbWFuYWdlbWVu dCIgYW5kIGlkZW50aWZpZXJzIGZvciBhIGdyYW50Lg0KDQpEYXZlDQoNCk9uIFR1ZSwgMTUgRGVj IDIwMjAgYXQgMTc6MzAsIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJp Y2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpPbiBEZWMgMTUsIDIwMjAsIGF0IDEwOjUwIEFNLCBEYXZl IFRvbmdlIDxkYXZlLnRvbmdlQG1vbmV5aHViLmNvbTxtYWlsdG86ZGF2ZS50b25nZUBtb25leWh1 Yi5jb20+PiB3cm90ZToNCg0KPiBUaGUgYWNjZXNzIHRva2VuIHBhdHRlcm4gaGFzIGEgbG90IG9m IGJlbmVmaXRzLCBvdGhlcndpc2Ugd2Ugd291bGRu4oCZdCBoYXZlIGFuIGVudGlyZSBPQXV0aCBl Y29zeXN0ZW0gYmFzZWQgb24gaXQNCg0KQnV0IHdoYXQgYXJlIHRoZSBiZW5lZml0cyBpbiB0aGlz IHBhcnRpY3VsYXIgdXNlIGNhc2U/IFRoZSBjb250aW51YXRpb24gQVBJIGlzIG5vdCBsaWtlIGFu eSBvdGhlciBBUEkgLSBpdCBpcyBpbnRlZ3JhbCB0byB0aGUgQVMuIFRoZXJlIGFyZSBxdWl0ZSBh IGZldyBleHRlbnNpb25zIHRvIE9BdXRoIHRoYXQgdXNlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBy YXRoZXIgdGhhbiBhY2Nlc3MgdG9rZW5zLg0KDQpZZXMsIGFuZCB0aGUgcHJvcGFnYXRpb24gb2Yg dGhhdCBoYXMgbGVhZCB0byBhIG1lc3MgaW4gdGhlIE9BdXRoIHdvcmxkLiBZb3XigJl2ZSBnb3Qg cmUtZGVmaW5pdGlvbnMgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9ucyBhdCBhbGwgZGlmZmVyZW50 IGVuZHBvaW50cywgdGhleeKAmXJlIHRlY2huaWNhbGx5IGFsbG93ZWQgdG8gdmFyeSBiZXR3ZWVu IGVuZHBvaW50cyAodGhvdWdoIEkgZG9u4oCZdCBrbm93IG9mIGl0IGhhcHBlbmluZyBpbiBwcmFj dGljZSwgdGhhdCBmZWVscyBsaWtlIGEgZG93bmdyYWRlIGF0dGFjayB3YWl0aW5nIHRvIGhhcHBl biB0byBzb21lb25lKS4gVGhlbiB0aGVyZeKAmXMgdGhlIGZhY3QgdGhhdCBhbGwgdGhlIG5ld2Vz dCBzZWN1cml0eSBtZWNoYW5pc21zIHdlIGhhdmUg4oCUIFBLQ0UsIERQb1AsIGFuZCBNVExTIOKA lCBkb27igJl0IHJlbHkgb24gY2xpZW50IGF1dGhlbnRpY2F0aW9uIGF0IGFsbCB0byBhY2hpZXZl IHNlY3VyaXR5LiBBbGwgb2YgdGhlc2Ugd29yayB3aXRob3V0IHRoZSBjbGllbnQgaGF2aW5nIGNy ZWRlbnRpYWxzIHByZXZpb3VzbHkga25vd24gdG8gdGhlIEFTLCBhbmQgd2UgYWxyZWFkeSBrbm93 IHRoYXQgR05BUCBpcyBnb2luZyB0byBuZWVkIHRvIGxpdmUgaW4gdGhpcyBtb3JlIGR5bmFtaWMg d29ybGQuIFdlIG5lZWQgdG8gdGhpbmsgYmV5b25kIHdoYXQgT0F1dGggMiBoYXMgZG9uZSBpbiB0 aGUgcGFzdCwgYW5kIGVzcGVjaWFsbHkgZnJvbSBvdXIgcGVyY2VwdGlvbnMgYW5kIGFzc3VtcHRp b25zIG9mIHRoZSBtb2RlbHMgdGhhdCBkcml2ZSBPQXV0aCAy4oCZcyBkZWNpc2lvbnMsIGxlc3Qg d2UgcmVwZWF0IGl0cyBtaXN0YWtlcy4NCg0KQWxzbywgSSB3YW50IHRvIGNoYWxsZW5nZSB0aGlz IGlkZWEgb2Yg4oCcaW50ZWdyYWwgdG8gdGhlIEFT4oCdIGFzIGEgcG9pbnQuIEluIE9BdXRoIDEs IHRoZSBBUEkgd2FzIOKAnGludGVncmFs4oCdIHRvIHRoZSBzZXJ2ZXIgc2lkZSwgYnV0IGluIE9B dXRoIDIgd2Ugc3BsaXQgdGhhdCBpbnRvIHRoZSBSUyBjb25jZXB0LiBFdmVuIHRob3VnaCBpbiBw cmFjdGljZSwgYSBsb3Qgb2YgUlPigJlzIGFyZSBzdGlsbCBpbnRlZ3JhdGVkIHRvIHRoZSBBUyBp biBzb21lIGZhc2hpb24gYmVjYXVzZSBpdOKAmXMgYSBzaW5nbGUgc2VydmljZSwgT0F1dGggMiBp cyBjbGVhciBhYm91dCB3aGF04oCZcyBleHBlY3RlZCB0byBiZSBrbm93biBieSBlYWNoIGNvbXBv bmVudC4gRm9yIHRoZSBBUyBhcyBjdXJyZW50bHkgZGVmaW5lZCBpbiBHTkFQLCBJ4oCZbSBzZWVp bmcgdGhyZWUgZGlzdGluY3QgZnVuY3Rpb25zLiBBcyBwZXIgdGhlIFRlcm1pbm9sb2d5IGRpc2N1 c3Npb24sIHdlIGRvbuKAmXQgaGF2ZSBleHBsaWNpdCBuYW1lcyBmb3IgdGhlc2UgeWV0Og0KDQog LSBzdGFydGluZyBhIHJlcXVlc3Q7IHRoaXMgaXMgYW4gZW5kcG9pbnQgdG8ga2ljayB0aGluZ3Mg b2ZmOyBpdCBuZWVkcyB0byBiZSBhYmxlIHRvIGxvb2sgdXAgdGhlIHJpZ2h0cyBhc2tlZCBmb3Ig YnkgdGhlIGNsaWVudCAoaWYgaXQga25vd3MgdGhlIGNsaWVudCBhdCBhbGwgYWhlYWQgb2YgdGlt ZSkgYW5kIG1ha2UgaW5pdGlhbCBkZWNpc2lvbnMgYWJvdXQgbmVlZGVkIGludGVyYWN0aW9uIGFu ZCBmb2xsb3cgdXANCiAtIGNvbnRpbnVpbmcgYSByZXF1ZXN0OyB0aGlzIGlzIGFuIEFQSSB0aGF0 IG5lZWRzIHRvIGtub3cgdGhlIGNvbnRleHQgb2YgdGhlIHJlcXVlc3QgaXRzZWxmLCBpbmNsdWRp bmcgd2hpY2gga2V5IGl04oCZcyBib3VuZCB0bzsgdGhpcyBpcyBzZXBhcmF0ZSBmcm9tIGFueSBp ZGVudGl0eSBvZiB0aGUgY2xpZW50IGFuZCBwb3NzaWJseSB0aGUgdXNlciwgYnV0IGFuIEFTIGlt cGxlbWVudGF0aW9uIHRoYXQgaGFzIGFjY2VzcyB0byB0aG9zZSBlbGVtZW50cyBjYW4gdXNlIHRo ZW0NCiAtIGludGVyYWN0aW5nIHdpdGggdGhlIHVzZXI7IHRoaXMgaXMgZnJvbnQtZmFjaW5nIGFu ZCBpbiBPQXV0aCB0b2RheSBpcyBhbHJlYWR5IGRlcGxveWVkIGFzIGEgc2VwYXJhdGUgc2Vydmlj ZSBpbiBzb21lIHBsYWNlcywgd2Ugc2hvdWxkIGVtYnJhY2UgdGhhdCBhdCB0aGUgdmVyeSBsZWFz dCAoYnV0IGRvaW5nIHNvIGZvcm1hbGx5IGlzIGEgc2VwYXJhdGUgaXNzdWUpDQoNCldoeSBzZXBh cmF0ZSB0aGVzZSBpbiB0aGlzIHdheT8gVGhlcmUgaXMgaW1tZW5zZSBwb3dlciBpbiBoYXZpbmcg YSBzaW5nbGUgY29uc2lzdGVudCB3YXkgdG8gc3RhcnQgdGhlIHByb2Nlc3MuIFRoZSDigJxjb250 aW51YXRpb24gQVBJ4oCdIGdpdmVzIHVzIGFuIEhUVFAtZGVmaW5lZCBtZWNoYW5pc20gZm9yIG1h bmFnaW5nIGEgcmVxdWVzdCBvdmVyIHRpbWUsIGluY2x1ZGluZyB0aGUgc2ltcGxlIGNhc2Ugb2Yg cmV0dXJuaW5nIGluZm9ybWF0aW9uIGZyb20gdGhlIGZyb250IGNoYW5uZWwsIGJ1dCBwZW9wbGUg aGF2ZSBhbHJlYWR5IHJhaXNlZCB0aGUgcXVlc3Rpb24gb2Ygbm9uLUhUVFAgYW5kIHNlbGYtaG9z dGVkIEFT4oCZcywgd2hpY2ggd291bGQgcHJvYmFibHkgd2FudCBhIGRpZmZlcmVudCBraW5kIG9m IGNvbnRpbnVhdGlvbiBBUEkgdG8gY29tbXVuaWNhdGUgdG8gdGhlIEFTLiBUaGUgc2FtZSB0aGlu ZyB3aXRoIHNlcGFyYXRpbmcgb3V0IHRoZSBpbnRlcmFjdGlvbjogdGhlcmUgYXJlIGdvaW5nIHRv IGJlIGEgbG90IG9mIGRpZmZlcmVudCB3YXlzIHRvIGhhbmRsZSBpbnRlcmFjdGlvbiBvdXQgdGhl cmUsIGFuZCBub3QgYWxsIG9mIHRoZW0gd2lsbCBiZSDigJxpbnRlZ3JhbOKAnSB0byB0aGUgQVMg aW4gdGhlIHdheSB0aGF0IGEgc2ltcGxlIGltcGxlbWVudGF0aW9uIG1pZ2h0IGRvLiBXZeKAmXJl IGRlZmluaW5nIGEgcHJvdG9jb2wgYmFzZWQgc3Ryb25nbHkgb24gSFRUUCBhbmQgSlNPTiwgYnV0 IHdlIHNob3VsZCBzdHJ1Y3R1cmUgaXQgaW4gc3VjaCBhIHdheSB0aGF0IGl0IGNhbiBiZSBleHRl bmRlZCBhbmQgdHJhbnNsYXRlZCBlbHNld2hlcmUgaW4gYSBjbGVhciB3YXkuDQoNClRoaXMgYWxs IHJhaXNlcyB0aGUgcXVlc3Rpb246IGlmIHdlIGNhbiByZWx5IG9uIGEgdW5pcXVlIFVSTCBmb3Ig cmVkaXJlY3QtYmFzZWQgaW50ZXJhY3Rpb24sIHdoeSBub3QgaGVyZT8gVGhlIHNpbXBsZSByZWFz b24gaXMgdGhhdCBhIFVSTCBpcyB0aGUgOm9ubHk6IG1lY2hhbmlzbSB3ZSBoYXZlIGluIHRoZSBm cm9udCBjaGFubmVsIGZvciBwYXNzaW5nIGluZm9ybWF0aW9uLCBhbmQgd2UgbmVlZCB0byB3YXJu IGltcGxlbWVudG9ycyBhZ2FpbnN0IGluY2x1ZGluZyBzZW5zaXRpdmUgaW5mb3JtYXRpb24gaW4g aXQsIGFuZCB3ZSBuZWVkIHRvIHByb3RlY3QgaXQgd2l0aCBhZGRpdGlvbmFsIGl0ZW1zLiBXZSBo YXZlIGFjY2VzcyB0byBtb3JlIHRoYW4ganVzdCBVUkxzIHdoZW4gd2XigJlyZSBkZWFsaW5nIHdp dGggdGhlIGNvbnRpbnVhdGlvbiBBUEksIGFuZCB3ZSBvdWdodCB0byBtYWtlIHVzZSBvZiBhbGwg b2Ygb3VyIHRvb2xzIGluIHdheXMgdGhhdCBhcmUgY29uc2lzdGVudCBhbmQgbWFrZSBzZW5zZS4N Cg0KRnJvbSBhIHByZXZpb3VzIGVtYWlsIHRoZSBhZHZhbnRhZ2VzIEkgc2VlIGFyZToNCiAtIG1v cmUgZGF0YSBjYW4gYmUgZW5jb2RlZCBpbiBhIHRva2VuIHRoYW4gaW4gYSB1cmkgKHRoaXMgc2Vl bXMgbW9yZSBvZiBhbiBlZGdlIGNhc2UpDQogLSBpdCBjYW4gYmUgYW4gaWRlbnRpZmllciBmb3Ig dGhlIGdyYW50IChJIGRvbid0IGFncmVlIHdpdGggdGhpcykNCg0KSXQgYWxsb3dzIHRoZSBwYXJ0 cyBhYm92ZSB0byBsaXZlIHNlcGFyYXRlbHksIGV2ZW4gaWYgdGhleSBkb27igJl0IEhBVkUgdG8u IEFuZCBpdCBzaW1wbGlmaWVzIHdoYXQgd2XigJlyZSBhc2tpbmcgdGhlIGNsaWVudCB0byBkbyBi eSBtYWtpbmcgaXQgY29uc2lzdGVudCB3aXRoIG90aGVyIHBhcnRzIG9mIHRoZSBlY29zeXN0ZW0u IFRoZSBBUyBvZmZlcmluZyBhbiBBUEkgZG9lc27igJl0IDpoYXZlOiB0byBiZSBkaWZmZXJlbnQs IGFuZCBPcGVuSUQgQ29ubmVjdCBzaG93ZWQgdXMsIHdpdGggdGhlIFVzZXJJbmZvIEVuZHBvaW50 LCB0aGF0IHRoYXTigJlzIHZlcnkgbXVjaCB0aGUgY2FzZSBpbiBwcmFjdGljZS4NCg0KSGF2aW5n IG15IGNsaWVudCBjb2RlIGRvIHZlcnkgc2ltaWxhciB0aGluZ3MgaW4gc2xpZ2h0bHkgZGlmZmVy ZW50IHdheXMgaXMgbm90IHNpbXBsZXIuDQoNCg0KQW5vdGhlciBxdWVzdGlvbiBJIGhhdmU6IGRv IHdlIGVudmlzYWdlIGdyYW50aW5nIGFjY2VzcyB0b2tlbnMgdG8gdGhlIFJDIHRoYXQgd2lsbCBh bGxvdyBpdCB0byBtYW5hZ2UgbXVsdGlwbGUgZ3JhbnRzPw0KDQpJIGRvbuKAmXQgc2VlIHRoYXQg aGFwcGVuaW5nLCBwZXJzb25hbGx5LCBhbmQgaXQgaGFzbuKAmXQgYmVlbiBicm91Z2h0IHVwIGFz IGEgdXNlIGNhc2UgdG8gZGF0ZS4NCg0KDQpJIGFsc28gdGhpbmsgdGhlcmUgd2lsbCBiZSBjb25m dXNpb24gd2l0aCB0aGUgc2lnbmluZyBiZWluZyB1c2VkIGZvciBkaWZmZXJlbnQgdGhpbmdzLiBN YXliZSBpdCBqdXN0IG5lZWRzIHRvIGJlIGNhbGxlZCBvdXQgaW4gdGhlIHNwZWMgdGhhdDoNCg0K UmVxdWVzdCAxOiBzaWduYXR1cmUgPSBjbGllbnQgYXV0aGVudGljYXRpb24NClJlcXVlc3QgMis6 IHNpZ25hdHVyZSA9IHByb29mIG9mIHBvc3Nlc3Npb24gZm9yIGFjY2VzcyB0b2tlbg0KDQoNClRo YXTigJlzIG1vcmUgb3IgbGVzcyB0aGUgaW50ZW50IG9mIHdoYXTigJlzIGluIHRoZSBzcGVjaWZp Y2F0aW9uIHJpZ2h0IG5vdywgYW5kIHdoeSBhbGwgdGhlIHNpZ25hdHVyZSBtZXRob2RzLCB3aGlj aCBhcmUgdXNlZCBmb3IgYm90aCBjbGllbnQgYXV0aCBhbmQgdG9rZW4gcG9zc2Vzc2lvbiwgYXJl IGFsbCB0b2dldGhlciBpbiBzZWN0aW9uIDggYW5kIG5vdCBzZXBhcmF0ZWQgYnkgdXNlLiAgKFdp dGggdGhlIGNhdmVhdDogaXTigJlzIG9ubHkgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIHRoZSBm aXJzdCByZXF1ZXN0IGlmIHRoZSBBUyBrbm93cyBhYm91dCB0aGUgY2xpZW50IGluc3RhbmNlIGFo ZWFkIG9mIHRpbWUsIHdoaWNoIGlzbuKAmXQgYWx3YXlzIGdvaW5nIHRvIGJlIHRydWUuKSBUaGF0 IGFsbCBjYW4gbGlrZWx5IGJlIG1hZGUgY2xlYXJlciwgYXMgaXMgYWx3YXlzIHRoZSBjYXNlIHdp dGggc3BlYyB0ZXh0LiBCdXQgeW91IGNhbiB1c2UgdGhlIHNpZ25hdHVyZSBtZXRob2RzIHdpdGgg YW5kIHdpdGhvdXQgYWNjZXNzIHRva2VucywgYW5kIGl0IG9ubHkgZ2V0cyB1c2VkIHdpdGhvdXQg aW4gYW4gaW5pdGlhbCBjYWxsIHdoZXJlIHlvdSBkb27igJl0IDpoYXZlOiBhbiBhY2Nlc3MgdG9r ZW4gdG8gcHJlc2VudC4NCg0KU2VwYXJhdGluZyB0aGUgZGlmZmVyZW50IGtpbmRzIG9mIOKAnGNs aWVudCBhdXRoZW50aWNhdGlvbiIgb3V0IGluIE9BdXRoIGlzIHRoZSBzb3VyY2Ugb2Ygc29tZSBy ZWFsIGNvbmZ1c2lvbi4gTGlrZSByaWdodCBub3csIHdoYXQgaGFwcGVucyBpZiB5b3UgdHJ5IHRv IGNvbWJpbmUgYSBjbGllbnQgYXNzZXJ0aW9uLCBzaWduZWQgcmVxdWVzdCBvYmplY3RzIGZvciBQ QVIsIGFuZCBEUG9QIHByb29mcywgYWxsIGluIGEgc2luZ2xlIHJlcXVlc3Q/IEFsbCBvZiB0aGVz ZSBhcmUgb3B0aW9uYWwgYW5kIGFsbCBvZiB0aGVtIOKAnGRvIGNsaWVudCBhdXRoZW50aWNhdGlv buKAnSBpbiBzb21lIGFyZ3VhYmxlIGZhc2hpb24uIEnigJl2ZSB3b3JrZWQgb24gc2V2ZXJhbCBz eXN0ZW1zIGFuZCBpbXBsZW1lbnRlZCB0aGVzZSB0aGluZ3MsIGFuZCB0aGVpciBpbnRlcnBsYXkg aXMgcmVhbGx5IGNvbmZ1c2luZyB0byBtYW5hZ2UgYW5kIGNhbiBnbyBzaWRld2F5cyByZWFsbHkg ZmFzdC4gQW5kIHRoYXTigJlzIGp1c3QgdGhlIHdvcmsgZm9yIGEgc2luZ2xlIGVuZHBvaW50LCB0 aGlzIGdldHMgcmVwZWF0ZWQgZm9yIGludHJvc3BlY3Rpb24sIHJldm9jYXRpb24sIENJQkEsIGRl dmljZSwgYW5kIG9uLg0KDQpBdCB0aGUgZW5kIG9mIHRoZSBkYXkgSeKAmW0gaW4gZmF2b3Igb2Yg Z2l2aW5nIHRoZSBjbGllbnQgZGV2ZWxvcGVycyBhIHZlcnkgY2xlYXIgc2V0IG9mIGRpcmVjdGlv bnMgb24gd2hhdCB0aGV5IG5lZWQgdG8gZG8gYW5kIGhvdyB0aGV5IG5lZWQgdG8gYWNjZXNzIHRo aW5ncywgYW5kIHRyZWF0aW5nIHRoZSBjb250aW51YXRpb24gYXMgYSB0b2tlbi1ib3VuZCBBUEkg aXMsIHRvIG1lLCB0aGUgY2xlYXJlc3QgcGF0dGVybiB3ZSBjYW4gb2ZmZXIgZm9yIHRoaXMgcGll Y2UuDQoNCiDigJQgSnVzdGluDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiBUdWUsIDE1IERlYyAyMDIw IGF0IDE1OjMzLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJA bWl0LmVkdT4+IHdyb3RlOg0KSSBhZ3JlZSB3aXRoIEZhYmllbiB0aGF0IHRoZSBwZXJzaXN0ZW50 IGlkZW50aWZpZXIgaXMgYSBzZXBhcmF0ZSBpc3N1ZS4gVGhlIGN1cnJlbnQgc3BlYyByZS11c2Vz IHRoZSBhY2Nlc3MgdG9rZW4gZm9yIHRoaXMgYXJ0aWZhY3QsIGJ1dCB0aGF04oCZcyBwb3RlbnRp YWxseSBicml0dGxlIGFuZCBjb3VsZCBiZSBjaGFuZ2VkIG91dCBmb3Igc29tZXRoaW5nIGVsc2Uu IFRoZXJl4oCZcyBhbiBpc3N1ZSBhc2tpbmcgZm9yIGV4cGFuZGluZyBvbiB0aGUgdXNlIGNhc2Vz IGZvciB0aGlzIGZ1bmN0aW9uYWxpdHkgKHdoaWNoIGhhc27igJl0IGJlZW4gYWRkcmVzc2VkIGJ5 IHRoaXMgUFIpOg0KDQpodHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1w cm90b2NvbC9pc3N1ZXMvODcNCg0KQSBwb3RlbnRpYWxseS1yb3RhdGluZyBVUkkgd291bGQgYmUg anVzdCBhcyBicml0dGxlLCBhbmQgc28gaGF2aW5nIGEgc2luZ2xlIGNvZGlmaWVkIGlkZW50aWZp ZXIgZm9yIHRoaXMgYXJ0aWZhY3Qgd291bGQgYmUgdXNlZnVsLCBidXQgaXQgZG9lcyBhc3N1bWUg c29tZSB0aGluZ3MgYWJvdXQgdGhlIG5hdHVyZSBvZiB0aGUgQVMuIEV2ZXJ5IG90aGVyIHVzZSB0 aGUgY2xpZW50IGhhcyB0byBtYW5hZ2UgdGhlIG9uZ29pbmcgcmVxdWVzdCBvdmVyIHRpbWUgZG9l c27igJl0IG5lZWQgYW4gZXhwbGljaXQgaWRlbnRpZmllci4gSnVzdCBsaWtlIHdpdGggT0F1dGgt cHJvdGVjdGVkIEFQSXMsIHRoZSBzZXJ2ZXIgY2FuIGRldGVybWluZSB0aGUgY29udGV4dCBub3Qg anVzdCBmcm9tIHRoZSBVUkkgYnV0IGZyb20gdGhlIHJlc3Qgb2YgdGhlIHJlcXVlc3QsIGluY2x1 ZGluZyB0aGUgYWNjZXNzIHRva2VuIGl0c2VsZi4gVGhpcyBpcyBib3RoIG1vcmUgY29tbW9uIGFu ZCBtb3JlIHBvd2VyZnVsIHRoYW4gYSBzdHJpY3QgcmVhZGluZyBvZiBSRVNUIGRlc2lnbnMuIEl0 IGFsc28gZm9sbG93cyB0aGUgSEFURU9TIHByaW5jaXBsZXMgYXMgdGhlIGVudGlyZSBIVFRQIHJl cXVlc3QgaXMgdGFrZW4gaW50byBhY2NvdW50LCBpbmNsdWRpbmcgdGhlIGFjY2VzcyB0b2tlbiBh bmQgc2lnbmF0dXJlIHBvcnRpb25zLg0KDQpJ4oCZbGwgYWxzbyBwb2ludCBvdXQgdGhhdCB0aGUg cm90YXRpb24gb2YgdGhlc2UgY3JlZGVudGlhbHMgaXMgYWxzbyBmaWxlZCBhcyBhIHNlcGFyYXRl IGlzc3VlIHRoYXTigJlzIG5vdCBiZWluZyBhZGRyZXNzZWQgcmlnaHQgbm93LCBzbyB3ZSBjYW4g cmV2aXNpdCB0aGF0IGRpc2N1c3Npb24gc2VwYXJhdGVseToNCg0KaHR0cHM6Ly9naXRodWIuY29t L2lldGYtd2ctZ25hcC9nbmFwLWNvcmUtcHJvdG9jb2wvaXNzdWVzLzg3DQoNCkFzIGZvciB0aGUg bmFtZSwgd2UgY291bGQgZ2l2ZSBpdCBhIGRpZmZlcmVudCBsYWJlbC4gV2UgaGF2ZSB0aGlzIHNh bWUgcGF0dGVybiBvZiBpc3N1aW5nIGEgcmVzb3VyY2Utc3BlY2lmaWMgYWNjZXNzIHRva2VuIGFs b25nc2lkZSBhIFVSTCBpbiB0aGUgRHluYW1pYyBSZWdpc3RyYXRpb24gc3BlY2lmaWNhdGlvbiwg Ym90aCBpbiBPQXV0aCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1OTIjc2VjdGlv bi0zKSBhbmQgT3BlbklEIENvbm5lY3QgKGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt Y29ubmVjdC1yZWdpc3RyYXRpb24tMV8wLmh0bWwjUmVnaXN0cmF0aW9uUmVzcG9uc2UpLiBIZXJl IGl04oCZcyBjYWxsZWQgdGhlIOKAnHJlZ2lzdHJhdGlvbiBhY2Nlc3MgdG9rZW7igJ0g4oCUIGJ1 dCB3aGF04oCZcyBpbXBvcnRhbnQgdGhlcmUsIGFzIGl0IGlzIGhlcmUsIGlzIHRoYXQgaXTigJlz IG5vdCBhIGRpZmZlcmVudCBraW5kIG9mIGFydGlmYWN0IHRoYXQgdGhlIGNsaWVudCBub3cgaGFz IHRvIGZpZ3VyZSBvdXQgaG93IHRvIHVzZSwgaXTigJlzIGFuIGFjY2VzcyB0b2tlbiBwbGFpbiBh bmQgc2ltcGxlLiBJbiB0aGUgT0F1dGggd29ybGQgdGhpcyBpcyBhIGJlYXJlciB0b2tlbiwgc2lu Y2UgdGhhdOKAmXMgd2hhdCBPQXV0aCAyIHVzZXMuIEluIHRoZSBHTkFQIHdvcmxkIGl04oCZbGwg YmUgYSBib3VuZCB0b2tlbiwgYXMgdGhhdOKAmXMgd2hhdCB3ZeKAmXJlIGxvb2tpbmcgdG8gYnVp bGQgb24uIFRoaXMgaXMgYWxzbyByZWxhdGVkIHRvIGFub3RoZXIgZnV0dXJlIGRpc2N1c3Npb24g YWJvdXQgcmVzcG9uc2VzIHR5aW5nIGFuIGFjY2VzcyB0b2tlbiB0byBhIHNwZWNpZmljIEFQSSB0 aGF04oCZcyB0b2xkIHRvIHRoZSBjbGllbnQsIGFzIHdlIGNvdWxkIHBvdGVudGlhbGx5IHJlLXVz ZSB0aG9zZSBjb21wb25lbnRzIGFuZCBjb25jZXB0cyBoZXJlIGFzIHdlbGw6DQoNCmh0dHBzOi8v Z2l0aHViLmNvbS9pZXRmLXdnLWduYXAvZ25hcC1jb3JlLXByb3RvY29sL2lzc3Vlcy82OQ0KDQpB bmQgZmluYWxseSwgbm8gc3BlY3VsYXRpb24gb24gdGhlIGNvbXBsZXhpdHkgaXMgbmVlZGVkOiBJ IGltcGxlbWVudGVkIHRoaXMgcGF0dGVybiBzZXZlcmFsIG1vbnRocyBhZ28gZHVyaW5nIHRoZSBk ZXNpZ24gdGVhbSBkaXNjdXNzaW9ucyB3aGVuIHdlIHdlcmUgY29uc2lkZXJpbmcgdGhpcyBwYXR0 ZXJuLCBhbmQgdGhlIGNvZGUgaXMgYWxsIG9ubGluZSBmb3IgcGVvcGxlIHRvIHNlZS4NCg0KaHR0 cHM6Ly9naXRodWIuY29tL2JzcGsvb2F1dGgueHl6LWphdmEvDQoNCk9uIHRoZSBBUyBzaWRlLCB0 aGUgbW9zdCBpbnRlcmVzdGluZyBjb2RlIHRvIHRoaXMgZGlzY3Vzc2lvbiBpcyBpbiB0aGUgVHJh bnNhY3Rpb25FbmRwb2ludCBjbGFzczoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2JzcGsvb2F1dGgu eHl6LWphdmEvYmxvYi9tYXN0ZXIvYXMvc3JjL21haW4vamF2YS9pby9ic3BrL29hdXRoL3h5ei9h dXRoc2VydmVyL2VuZHBvaW50L1RyYW5zYWN0aW9uRW5kcG9pbnQuamF2YQ0KDQpIZXJlLCB5b3Xi gJlsbCBzZWUgdGhhdCBvbiBpbml0aWFsIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgbG9va3MgdXAgdGhl IGNsaWVudCB0byBzZWUgaWYgaXTigJlzIGJlZW4gcmVnaXN0ZXJlZCwgYnV0IGFmdGVyIHRoYXQs IGl0IG1ha2VzIHN1cmUgdGhhdCB0aGUgdG9rZW4gYW5kIGtleSBhcmUgYXBwcm9wcmlhdGUgZm9y IHRoZSBvbmdvaW5nIHJlcXVlc3QuIEZyb20gdGhlIGNsaWVudCBzaWRlIGl04oCZcyBldmVuIHNp bXBsZXIuIFRoZSBjbGllbnTigJlzIGdvdCBhIHNtYWxsIHNlcnZpY2UgZnVuY3Rpb24gdG8gbWFu YWdlIHRoZSBkaWZmZXJlbnQgc2lnbmF0dXJlIG1ldGhvZHMgdGhhdCBhcmUgaW1wbGVtZW50ZWQs IGFuZCBhbGwgb2YgdGhlbSBjYW4gdGFrZSBpbiBhbiBvcHRpb25hbCBhY2Nlc3MgdG9rZW46DQoN Cmh0dHBzOi8vZ2l0aHViLmNvbS9ic3BrL29hdXRoLnh5ei1qYXZhL2Jsb2IvbWFzdGVyL3JjL3Ny Yy9tYWluL2phdmEvaW8vYnNway9vYXV0aC94eXovaHR0cC9TaWduaW5nUmVzdFRlbXBsYXRlU2Vy dmljZS5qYXZhDQoNClRoZSBoZWF2eSBsaWZ0IGlzIGRvaW5nIHRoZSBhY3R1YWwgc2lnbmluZywg YW5kIHlvdSBuZWVkIHRoYXQgaW4gb3JkZXIgdG8gc3RhcnQgdGhlIHByb2Nlc3MgYW55d2F5LiBN YW5hZ2luZyB0aGUgYWNjZXNzIHRva2VuIGFzIGFuIGFydGlmYWN0IHRvIHVzZSBhdCB0aGUgQVBJ IGlzIGNvbXBsZXRlbHkgdHJpdmlhbCBzaW5jZSB0aGUgY2xpZW50IGFscmVhZHkgbmVlZHMgdG8g bWFuYWdlIGl0cyBvd24gc3RhdGUgaW50ZXJuYWxseSB0byBkbyBhbnkgb2YgdGhpcy4gQW5kIG5v dGUgdGhhdCBhbGwgb2YgdGhpcyBpcyBjaGFuZ2VkIGZyb20gaG93IGl0IHdhcyBiZWZvcmU6IFBy ZXZpb3VzbHksIHRoZSBYWVogUHJvdG9jb2wgaGFkIHVzZWQgYSDigJx0cmFuc2FjdGlvbiBoYW5k bGXigJ0gcmV0dXJuZWQgYnkgdGhlIEFTIHRoYXQgdGhlIGNsaWVudCB3b3VsZCB1c2UgdG8gY29u dGludWUgdGhlIHJlcXVlc3QuIEhvd2V2ZXIsIHRoaXMgc2ltcGxlIG1vZGVsIHdhcyBsaW1pdGlu ZywgYW5kIHRoZSBkZXNpZ24gdGVhbSBhZG9wdGVkIFhBdXRo4oCZcyBtb2RlbCBvZiBjb250aW51 YXRpb24gYmVpbmcgYW4gQVBJLiBJbiBkb2luZyBzbywgd2UgbWFkZSBpdCBsaWtlIGFsbCBvZiB0 aGUgb3RoZXIgQVBJcyB0aGUgY2xpZW50IGlzIGdvaW5nIHRvIGNhbGw6IGluIHRoZSBpbml0aWFs IHN0YXRlLCBpdCBkb2VzbuKAmXQgaGF2ZSBhbnkga2luZCBvZiBhY2Nlc3MgcmlnaHRzLCBpdOKA mXMganVzdCBjYWxsaW5nLiBGcm9tIHRoYXQgaW5pdGlhbCBjYWxsIGZvcndhcmQsIHRoZSBBUyBq dXN0IG5lZWRzIHRvIGtub3cgdGhhdCB0aGUgdG9rZW4gYW5kIGtleSBtYXRjaCB3aGF0IGl0IGV4 cGVjdHMuDQoNCkluIHN1bW1hcnksIG15IHZpZXdzIGFyZToNCiAtIFRoZSBhY2Nlc3MgdG9rZW4g cGF0dGVybiBoYXMgYSBsb3Qgb2YgYmVuZWZpdHMsIG90aGVyd2lzZSB3ZSB3b3VsZG7igJl0IGhh dmUgYW4gZW50aXJlIE9BdXRoIGVjb3N5c3RlbSBiYXNlZCBvbiBpdA0KIC0gTWFnaWMgVVJJcyBo YXZlIGEgbG90IG9mIGRyYXdiYWNrcyB3aGljaCBhcmUgd2VsbCB1bmRlcnN0b29kOyB3aGlsZSB0 aGV5IGNhbiBiZSBtaXRpZ2F0ZWQsIHRoZXkgY2FuIGFsc28gYmUgYXZvaWRlZA0KIC0gQ29udGlu dWF0aW9uIGlzIGFuIEFQSSwgYW5kIHRyZWF0aW5nIGl0IGxpa2UgdGhlIG90aGVyIGtpbmRzIG9m IEFQSSB0aGUgY2xpZW50IHdvdWxkIGNhbGwgbWFrZXMgc2Vuc2UNCiAtIENhbGxpbmcgdGhpcyBi eSBhIHNwZWNpYWwgbmFtZSwgbGlrZSDigJxncmFudCBhY2Nlc3MgdG9rZW7igJ0gb3Ig4oCcY29u dGludWF0aW9uIGFjY2VzcyB0b2tlbuKAnSBpcyBmaW5lLCBidXQgaXQgc2hvdWxkIGZ1bmN0aW9u IGxpa2UgYW55IG90aGVyIGFjY2VzcyB0b2tlbg0KIC0gVGhlIGhlYXZ5IGxpZnQgZm9yIGNsaWVu dHMgaXMgb24gcHJvdGVjdGluZyB0aGUgbWVzc2FnZSBjcnlwdG9ncmFwaGljYWxseSwgd2hpY2gg dGhleSBuZWVkIHRvIGRvIGFueXdheQ0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIERlYyAxNSwgMjAy MCwgYXQgNzo1MCBBTSwgRGF2ZSBUb25nZSA8ZGF2ZS50b25nZUBtb25leWh1Yi5jb208bWFpbHRv OmRhdmUudG9uZ2VAbW9uZXlodWIuY29tPj4gd3JvdGU6DQoNClRoZSBwZXJzaXN0ZW50IGlkZW50 aWZpZXIgaXMgbm90IGEgZGlmZmVyZW50IGlzc3VlLCB0aGUgY3VycmVudCBhY2Nlc3MgdG9rZW4g aXMgdXNlZCB0byByZWZlcmVuY2UgYW4gZXhpc3RpbmcgZ3JhbnQ8aHR0cHM6Ly9naXRodWIuY29t L2lldGYtd2ctZ25hcC9nbmFwLWNvcmUtcHJvdG9jb2wvYmxvYi9tYWluL2RyYWZ0LWlldGYtZ25h cC1jb3JlLXByb3RvY29sLm1kI3JlZmVyZW5jaW5nLWFuLWV4aXN0aW5nLWdyYW50LXJlcXVlc3Qt cmVxdWVzdC1leGlzdGluZz4NCg0KSXQgbWF5IG5vdCBiZSBtb3JlIGRpZmZpY3VsdCBmb3IgYSBj bGllbnQgdG8gdXNlIGFuIGFjY2VzcyB0b2tlbiBhdCB0aGUgQVMgLyBSUy4gQnV0IHRoZXJlIGlz IGRlZmluaXRlbHkgYW4gb3ZlcmhlYWQgb24gdGhlIGNsaWVudCB0byBtYW5hZ2UgdGhpcyBzZXBh cmF0ZSBhY2Nlc3MgdG9rZW4uDQoNCg0KDQpPbiBUdWUsIDE1IERlYyAyMDIwIGF0IDEyOjEwLCBG YWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPG1haWx0bzpmYWJpZW4uaW1i YXVsdEBnbWFpbC5jb20+PiB3cm90ZToNCkkgdGhpbmsgd2UgYWx3YXlzIHNhaWQgdGhlIGFjY2Vz cyB0b2tlbiB3YXMgZGlmZmVyZW50LCBhbmQgaGFuZGxlZCBhcyBhIGJvdW5kIHRva2VuLg0KDQpC dXQgaXQgZG9lc24ndCBtZWFuIGl0J3MgbW9yZSBkaWZmaWN1bHQgZm9yIHRoZSBjbGllbnQgdGhh dCBhbHJlYWR5IG5lZWRzIHRvIGJlIGFibGUgdG8gaGFuZGxlIHRva2VucyBhbnl3YXkgKGJlYXJl ciBvciBub3QsIGJvdGggY2FzZXMgY291bGQgb2NjdXIpLiBJdCdzIG1vc3RseSBjb25zb2xpZGF0 aW5nIHRoZSBsb2dpYy4NCg0KWW91J3JlIGFudGljaXBhdGluZyBhIGxvdCBvZiBpc3N1ZXMgd2hp Y2ggaGF2ZSBubyBzcGVjaWZpYyByZWFzb24gdG8gb2NjdXIsIHN1Y2ggYXMgImNhbid0IGJlIHVz ZWQgd2l0aCB0aGUgdG9rZW4gbWFuYWdlbWVudCBBUElzPyIuIFRoZSBtYW5hZ2VtZW50IEFQSSBp cyBwYXJ0IG9mIHRoZSBzYW1lIGdlbmVyYWwgZmxvdy4NCkFudGljaXBhdGluZyBpc3N1ZXMgd2l0 aCByb3RhdGlvbiBpcyB1c2VmdWwsIGJ1dCB0aGVyZSBhcmUgYWxzbyBtYW55IHdheXMgaXQgY2Fu IGJlIGhhcmQgdG8gbWFuYWdlIHRocm91Z2ggYSBzdGF0ZWZ1bCBhcHByb2FjaCB0b28uIEFuZCBm dW5kYW1lbnRhbGx5LCBoYXZpbmcgZXZlcnl0aGluZyBpbiBhIGNvbW1vbiBtb2RlbCAoYm90aCBm b3IgdGhlIGludGVybmFscyBvZiB0aGUgQVMgYW5kIGZvciB0aGUgQVBJIGNhbGxzKSB3aWxsIGhl bHAgaW1wcm92ZSBieSBhIGxhcmdlIG1hcmdpbiB3aGF0IGlzIHByb2JhYmx5IHRoZSB3ZWFrZXN0 IHBvaW50IGluIHRvZGF5J3MgaW5mcmFzdHJ1Y3R1cmUuIEJ1dCBpdCdzIGVhcmx5IHRvIGJlIGRl ZmluaXRpdmUgYXMgdG8gdGhlIGRvd25zdHJlYW0gaW1wYWN0IGVpdGhlciB3YXkuDQoNCkFzIGZv ciBhIHBlcnNpc3RlbnQgaWRlbnRpZmllciBpbnN0ZWFkIG9mIGEgY29udGludWF0aW9uIEFQSSwg YW5kIGdlbmVyYWxseSB0aGUgZW5kIG9mIHlvdXIgbWVzc2FnZSwgaXQncyBhIHRvdGFsbHkgdW5y ZWxhdGVkIGlzc3VlIHRvIHRoaXMgUFIsIHNvIEkgc3VnZ2VzdCB3ZSBkb24ndCBkaXNjdXNzIHRo YXQgaGVyZSwgYnV0IGluIGEgc2VwYXJhdGUgaXNzdWUgaWYgbmVlZGVkLg0KDQpGYWJpZW4NCg0K T24gVHVlLCBEZWMgMTUsIDIwMjAgYXQgMTE6MDggQU0gRGF2ZSBUb25nZSA8ZGF2ZS50b25nZUBt b25leWh1Yi5jb208bWFpbHRvOmRhdmUudG9uZ2VAbW9uZXlodWIuY29tPj4gd3JvdGU6DQpTbyB3 ZSd2ZSBlc3RhYmxpc2hlZCB0aGF0IHRoaXMgaXMgYSBkaWZmZXJlbnQgYWNjZXNzIHRva2VuLCB0 aGF0IHJlcXVpcmVzIGRpZmZlcmVudCBoYW5kbGluZyBhdCB0aGUgY2xpZW50LiBTbyBrZWVwaW5n IGl0IGNvdWxkIGNhdXNlIG1vcmUgY29uZnVzaW9uPw0KDQpBcyBhbiBSQywgSSB3aWxsIGhhdmUg dG8gc3RvcmUgdGhlIGNvbnRpbnVlIGB1cmlgIGFzIGFsdGhvdWdoIGl0IGNvdWxkIGJlIHN0YXRp YyBpdCBjb3VsZCBhbHNvIGJlIGR5bmFtaWMuIFdoeSBkbyBJIG5lZWQgdG8gc3RvcmUgYW4gYWNj ZXNzIHRva2VuIGFzIHdlbGwuIEl0IGJyaW5ncyBtZSBubyBiZW5lZml0IGFzIGFuIFJDLCBpbiBm YWN0IGl0IGJyaW5ncyBtb3JlIGNvbXBsZXhpdHkuIEFzIEkgd2lsbCBub3cgbmVlZCB0byBtYW5h Z2UgbXVsdGlwbGUgdHlwZXMgb2YgdG9rZW5zIHdpdGggZGlmZmVyZW50IGxpZmVjeWNsZXM6DQoN CkNvbnRpbnVhdGlvbiB0b2tlbg0KICAtIGNhbiBvbmx5IGJlIHVzZWQgYXQgdGhlIGNvbnRpbnVl IGVuZHBvaW50ICh0aGUgbmFtZSBvZiB3aGljaCBpcyBjb25mdXNpbmcgYXMgSSBjYW4gdXNlIHRo aXMgZW5kcG9pbnQgdG8gcmV2b2tlIGEgZ3JhbnQgb3IgZ2V0IG1ldGFkYXRhIG9uIHRoZSBncmFu dCkuDQogLSBtYXkgYmUgcm90YXRlZCBlYWNoIHRpbWUgaXQgaXMgdXNlZCwgb3IgbWF5IG5vdCBi ZQ0KIC0gcHJvdmlkZWQgaW4gdGhlIGBjb250aW51ZWAgc2VjdGlvbiBvZiB0aGUgcmVzcG9uc2UN CiAtIG11c3QgYmUgc2VuZGVyLWNvbnN0cmFpbmVkDQogLSBjYW4ndCBiZSB1c2VkIHdpdGggdGhl IHRva2VuIG1hbmFnZW1lbnQgQVBJcz8NCiAtIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5IHRoZSBn cmFudCB3aGVuIG1ha2luZyBzdWJzZXF1ZW50IGdyYW50cw0KDQpBY2Nlc3MgdG9rZW4ocykgdG8g dXNlIGF0IFJTDQogIC0gY2FuIG9ubHkgYmUgdXNlZCBhdCB0aGUgc3BlY2lmaWVkIFJTDQogIC0g bWF5IGJlIHNlbmRlciBjb25zdHJhaW5lZA0KICAtIHdoZW4gdXNlZCBhdCB0aGUgUlMsIHdpbGwg bm90IHJlc3VsdCBpbiByb3RhdGlvbg0KDQpGcm9tIG15IHBlcnNwZWN0aXZlLCBtb3N0IHVzZS1j YXNlcyB3aWxsIHJlcXVpcmUgdGhlIFJDIHRvIGhhdmUgYSBwZXJzaXN0ZW50IGlkZW50aWZpZXIg Zm9yIHRoZSBncmFudC4gV2h5IG5vdCBicmluZyB0aGlzIGludG8gdGhlIHByb3RvY29sIGFuZCBs ZXQgdGhlIEFTIHByb3ZpZGUgdGhpcyBwZXJzaXN0ZW50IGlkZW50aWZpZXIgKHRocm91Z2ggdGhl IGZvcm0gb2YgdGhlIGNvbnRpbnVlIHVyaSkuIFVzaW5nIGEgcm90YXRpbmcgYWNjZXNzIHRva2Vu IGFzIGEgcGVyc2lzdGVudCBpZGVudGlmaWVyIGRvZXNuJ3Qgc2VlbSBsaWtlIHRoZSByaWdodCBj aG9pY2UuDQoNCkkgc2VlIG5vIHNlY3VyaXR5IGJlbmVmaXQgdG8gaGF2aW5nIHRoZSBjb250aW51 YXRpb24gYWNjZXNzIHRva2VuLiBJdCBkb2Vzbid0IG1hdHRlciBpZiB0aGUgY29udGludWUgdXJp IGxlYWtzIGFzIGl0IGlzIHVzZWxlc3Mgd2l0aG91dCBhbiBhY2NvbXBhbnlpbmcgc2lnbmF0dXJl LCBpLmUuIGFueSBzZWN1cml0eSBiZW5lZml0IG9mIGhhdmluZyBhbiBhY2Nlc3MgdG9rZW4gaXMg YWxyZWFkeSBwcm92aWRlZCBieSBoYXZpbmcgYSBzaWduYXR1cmUuDQoNClRoZSBvbmx5IGJlbmVm aXRzIHRoYXQgSSBjYW4gc2VlIGFyZToNCiAtIElmIHRoZSBBUyB3YW50cyB0byBiZSBmdWxseSBz dGF0ZWxlc3MsIHRoZW4geW91IGNhbiBlbmNvZGUgbW9yZSBkYXRhIGluIGEgdG9rZW4gdGhhbiBp biBhIHVyaQ0KIC0gSWYgdGhlIEFTIHdhbnRzIHRvIGhhdmUgYSBzdGF0aWMgZW5kcG9pbnQgZm9y IENSVUQgb3BlcmF0aW9ucyBvbiB0aGUgZ3JhbnQNCiAtIFRvIGFsbG93IHRoZSBBUyB0byBpZGVu dGl0eSBhIHByZXZpb3VzIGdyYW50DQoNCklmIHdlIGRyb3BwZWQgdGhlIGFjY2VzcyB0b2tlbiBm b3IgdGhlIGNvbnRpbnVlIGVuZHBvaW50IGFuZCByYXRoZXIgbWFuZGF0ZWQgYSBkeW5hbWljIHVy aSB0aGlzIHdvdWxkIG1ha2UgdGhpbmdzIGNvbmNlcHR1YWxseSBlYXNpZXIgdG8gdW5kZXJzdGFu ZCwgZWFzaWVyIGZvciB0aGUgUkMgdG8gaW1wbGVtZW50LCBlYXNpZXIgdG8gZGVidWcgYW5kIGxl c3MgY2hhbmNlIG9mIGVycm9ycyB3aGVuIHJvdGF0aW5nIHRva2VucyAoaS5lLiByYWNlIGNvbmRp dGlvbnMgY291bGQgYmUgcXVpdGUgbGlrZWx5IGlmIHRoZSBBUyBhbHdheXMgcm90YXRlcyB0aGUg dG9rZW4pDQoNCk9uZS1vZmYgZ3JhbnQgd2l0aCBubyBjb250aW51YXRpb24gb3Igb25nb2luZyBt YW5hZ2VtZW50Og0KUkMgc2VuZHMgc2lnbmF0dXJlIGFuZCBtZXRhZGF0YSwgbm8gYGNvbnRpbnVl YCByZXNwb25zZSBwcm92aWRlZCwgdGhlcmVmb3JlIG5vIGdyYW50IG1hbmFnZW1lbnQgcG9zc2li bGUNCg0KR3JhbnQgd2l0aCBvbmdvaW5nIG1hbmFnZW1lbnQNClJDIHNlbmRzIHNpZ25hdHVyZSBh bmQgbWV0YWRhdGEsIEFTIHJlc3BvbmRzIHdpdGggYSBjb250aW51ZSB1cmkgdGhhdCBoYXMgdGhl c2UgcHVycG9zZXM6DQogLSBjYW4gYmUgdXNlZCBieSB0aGUgUkMgdG8gY29udGludWUvdXBkYXRl LCByZWFkIG9yIHJldm9rZSB0aGUgZ3JhbnQNCiAtIGNhbiBiZSB1c2VkIGJ5IHRoZSBSQyB3aGVu IG1ha2luZyBhIG5ldyBncmFudCB0byBpZGVudGlmeSB0aGUgcHJldmlvdXMgZ3JhbnQNCg0KQXMg YW4gUkMgdGhlIG9ubHkgcGVybWFuZW50IGl0ZW1zIEkgbmVlZCB0byBzdG9yZSBhcmU6DQogLSB0 aGUgY29udGludWUgdXJpIGFzc29jaWF0ZWQgd2l0aCB0aGUgZ3JhbnQNCiAtIGFueSBhY2Nlc3Mg dG9rZW5zIEkgcmVjZWl2ZSBmb3IgdGhlIGdyYW50DQoNCkRhdmUNCg0KT24gVHVlLCAxNSBEZWMg MjAyMCBhdCAxMDoxMSwgRmFiaWVuIEltYmF1bHQgPGZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbTxt YWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBUb3JzdGVuLA0KDQpZ b3UncmUgcmlnaHQgb24gYm90aCBhY2NvdW50cy4NCi0gZm9yIHRoZSBmaXJzdCByZW1hcmssIGl0 IGZpdHMgcXVpdGUgbmljZWx5IHRoZSBpbml0IHJlcXVlc3QgIC8gY29udGludWF0aW9uIHBhdHRl cm4NCi0gZm9yIHRoZSBzZWNvbmQgcmVtYXJrLCBpdCBpcyBhIHNvcnQgb2YgaGFuZGxlIGZvciB0 aGUgY29udGludWF0aW9uIHJlcXVlc3QsIHdoaWNoIHdpbGwgZXZlbnR1YWxseSBsZWFkIHRvIHRo ZSBpc3N1YW5jZSBvciByZWZyZXNoIG9mIHN0YW5kYXJkIGFjY2VzcyB0b2tlbnMNCg0KSGF2aW5n IGEgc3BlY2lmaWMgbmFtZSBpcyBhIHBvc3NpYmlsaXR5LCBJIGFjdHVhbGx5IHN1Z2dlc3RlZCB0 aGF0IHRvbyBhdCBzb21lIHBvaW50Lg0KDQpGYWJpZW4NCg0KT24gVHVlLCBEZWMgMTUsIDIwMjAg YXQgOTo1MCBBTSBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCkhpIEZhYmllbiwNCg0KPiBB bSAxMi4xMi4yMDIwIHVtIDEyOjA2IHNjaHJpZWIgRmFiaWVuIEltYmF1bHQgPGZhYmllbi5pbWJh dWx0QGdtYWlsLmNvbTxtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPj46DQo+DQo+IEhp LA0KPg0KPiBPbiB0aGUgY29udHJhcnkgeW91ciBmZWVkYmFjayBpcyBtb3N0IHdlbGNvbWUuDQo+ DQo+IEl0IGRvZXNuJ3QgYWNjZXB0IGFueSB0b2tlbiwgaXQgbmVlZHMgdGhlIHBhcnRpY3VsYXIg dG9rZW4gYXMgZGVzY3JpYmVkIGluIDMuMSBhbmQgd2hpY2ggaXMgbm90IGEgYmVhcmVyIHRva2Vu ICh0aGF0J3Mgd2hhdCB0aGUgImtleSIgOiB0cnVlIHBhcmFtZXRlciBpcyBzdXBwb3NlZCB0byBj b252ZXkpLg0KPg0KPiBMZXQgdXMga25vdyBpZiB5b3UgbmVlZCBtb3JlIGNsYXJpZmljYXRpb25z Lg0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBJIHRoaW5rIG9ubHkgYWNjZXB0aW5n IHRoaXMga2luZCBvZiB0b2tlbiBhdCB0aGUgY29udGludWF0aW9uIGlzIGEgZ29vZCBpZGVhIG90 aGVyd2lzZSB0aGUgQVMgd291bGQgbmVlZCB0byBiZSBhYmxlIHRvIHBhcnNlIGFuZCB1bmRlcnN0 YW5kIGFsbCBzb3J0cyBvZiBhY2Nlc3MgdG9rZW5zLg0KDQpDb25jZXB0dWFsbHksIEkgbGlrZSB0 aGUgaWRlYSB0byB0cmVhdCB0aGUgY29udGludWF0aW9uIGFzIGFub3RoZXIga2luZCBvZiByZXNv dXJjZS4gSG93ZXZlciwgaGVyZSBhcmUgc29tZSBvYnNlcnZhdGlvbnMgSSB3YW50IHRvIHNoYXJl IHdpdGggeW91Og0KLSBUaGlzIHJlc291cmNlIGlzIGRpZmZlcmVudCBhcyBpdCB3aWxsIGlzc3Vl IG90aGVyIGFjY2VzcyB0b2tlbnMgKG9mIHRoaXMga2luZCkgdG8gYmUgdXNlZCBpbiBzdWJzZXF1 ZW50IGNvbnRpbnVhdGlvbiByZXF1ZXN0cy4gVGhpcyByZXF1aXJlcyBkaWZmZXJlbnQgaGFuZGlu ZyBvbiB0aGUgY2xpZW50IHNpZGUuDQotIFRoaXMgYWNjZXNzIHRva2VuIChpZiBJIHVuZGVyc3Rh bmQgY29ycmVjdGx5KSBpcyAob3IgYXQgbGVhc3QgZmVlbHMgbGlrZSkgYSBoYW5kbGUgZm9yIHRo ZSB1bmRlcmx5aW5nIGdyYW50LiBTbyBpdCBpcyBraW5kIG9mIHRoZSBzdXBlciBhY2Nlc3MgdG9r ZW4gdG8gb2J0YWluIG90aGVyIGFjY2VzcyB0b2tlbnMuDQoNCkkgd291bGQgY29uc2lkZXIgdXNp bmcgYSBkaWZmZXJlbnQgdGVybSB0byByZWZlciB0byB0aGlzIHNwZWNpYWwgYWNjZXNzIHRva2Vu LCBncmFudCB0b2tlbiBvciBncmFudCBoYW5kbGUgZm9yIGV4YW1wbGUsIGluIG9yZGVyIHRvIHBy ZXZlbnQgY29uZnVzaW9uLg0KDQpiZXN0IHJlZ2FyZHMsDQpUb3JzdGVuLg0KDQoNCj4NCj4gQmVz dA0KPiBGYWJpZW4NCj4NCj4gTGUgc2FtLiAxMiBkw6ljLiAyMDIwIMOgIDExOjMzLCBUb3JzdGVu IExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ+PiBhIMOpY3JpdCA6DQo+IEhpIGFsbCwNCj4NCj4gSSBkaWRu4oCZdCBmb2xs b3cgR05BUCBjbG9zZWx5IHNvIGJlYXIgd2l0aCBtZSBpZiBtZSBxdWVzdGlvbiBzZWVtcyBuYWl2 ZS4NCj4NCj4gQWZ0ZXIgaGF2aW5nIHNraW1tZWQgdGhyb3VnaCB0aGUgY3VycmVudCBkcmFmdCBh bmQgdGhlIFBSLCBJ4oCYbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBjb250aW51YXRpb24gcmVxdWVz dHMgYWNjZXB0cyBhbnkgYWNjZXNzIHRva2VuIGlzc3VlZCB0byB0aGUgUkMgb3IgdGhlIHBhcnRp Y3VsYXIgYWNjZXNzIHRva2VuIHJldHVybmVkIGluIHRoZSDigJ5jb250aW51ZeKAnCBlbGVtZW50 IGluIHNlY3Rpb24gMy4xLi4NCj4NCj4gQ2FuIHlvdSBwbGVhc2Ugc2hlZCBzb21lIGxpZ2h0IG9u IHRoaXM/DQo+DQo+IGtpbmQgcmVnYXJkcywNCj4gVG9yc3Rlbi4NCj4NCj4+IEFtIDEyLjEyLjIw MjAgdW0gMDM6MzUgc2NocmllYiBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwu Y29tPG1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+PjoNCj4+DQo+PiDvu78NCj4+IFlv dSdyZSBjb21wbGV0ZWx5IHJpZ2h0LiBBbGxvd2luZyB0aGUgZGV2IHRvIGJlIGxhenkgaXMgYSB2 ZXJ5IGdvb2QgdGhpbmcgaW4gZ2VuZXJhbCwgYmVjYXVzZSBpdCdzIHdoYXQgd2Uga25vdyB3aWxs IHdvcmsgOi0pDQo+Pg0KPj4gTGUgc2FtLiAxMiBkw6ljLiAyMDIwIMOgIDAzOjE1LCBTdGVwaGVu IE1vb3JlIDxzcm1vb3JlQGdtYWlsLmNvbTxtYWlsdG86c3Jtb29yZUBnbWFpbC5jb20+PiBhIMOp Y3JpdCA6DQo+PiBIaSBGYWJpZW4sDQo+Pg0KPj4gRm9yICMzKSBFdmVuIGFmdGVyIEkgdHlwZWQg b3V0IHRoZSBoeXBvdGhldGljYWwgYXR0YWNrLCB0aGF0IHdhcyBzb3J0IG9mIGluIHRoZSBiYWNr IG9mIG15IG1pbmQsIGl0IGlzbid0IGEgaHVnZSByaXNrIHRoZXJlLiBTbyBJIGFjdHVhbGx5IGFn cmVlIHdpdGggRGljayB0aGVyZS4gU29tZXRoaW5nIGRvZXNuJ3Qgc2l0IHJpZ2h0IHdpdGggbWUg Zm9yIHRoZSB1bmlxdWUgVVJMIHNvbHV0aW9uLCBzbyBJIGRvbid0IGxpa2UgaXQgYW5kIGNhbWUg dXAgd2l0aCBhIGh5cG90aGV0aWNhbCB0aGF0IHNlZW1zIGxpa2UgaXQgY291bGQgYmUgYSBkb3du IHNpZGUuDQo+Pg0KPj4gSSBzdGlsbCB0aGluayB0aGUgYWNjZXNzIHRva2VuIG1vZGVsIHdpdGgg dGhlIHNpZ25lZCByZXF1ZXN0IGlzIHRoZSB3YXkgSSdkIGxpa2UgdG8gZ28sIGJlY2F1c2UgYWdh aW4sIGl0J3MgYSBtZWNoYW5pc20gSSdkIGJlIGltcGxlbWVudGluZyBhbnl3YXkgdG8gdGFsayB0 byBhbnkgJ25vcm1hbCcgcmVzb3VyY2UuIFRoZSBmYWN0IGlzIHRoZXJlIGlzIF9zb21ldGhpbmdf IHJlcHJlc2VudGluZyBjb250ZXh0IHRoYXQgaGFzIHRvIHBhc3MgYmFjayBhbmQgZm9ydGggaGVy ZSwgd2hldGhlciB0aGF0IGlzIGFuIGFjY2VzcyB0b2tlbiAod2hpY2ggSSBmZWVsIGxpa2UgaXMg bW9yZSBmbGV4aWJsZSBmb3IgZXh0ZW5zaW9ucyBldGMpLCBhIHVuaXF1ZSB1cmwsIG9yIGV2ZW4g YSBjb29raWUgc2VudCBpbiB0aGUgY29va2llIGhlYWRlci4gU28ganVzdCB0byByZS1pdGVyYXRl LCBJJ20gYSArMSBvbiB0aGlzIHB1bGwgcmVxdWVzdCwgc3BlYWtpbmcgYXMgYSBsYXp5IGRldmVs b3BlciA7KQ0KPj4gLXN0ZXZlDQo+Pg0KPj4gT24gRnJpLCBEZWMgMTEsIDIwMjAgYXQgODo1MSBQ TSBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPG1haWx0bzpmYWJpZW4u aW1iYXVsdEBnbWFpbC5jb20+PiB3cm90ZToNCj4+IEFnYWluIHNwZWFraW5nIGluIG15IG93biBu YW1lIGhlcmUuDQo+Pg0KPj4gRGljaywgd2Uga25vdyB5b3UnZCBwcmVmZXIgdG8gaGF2ZSBhIGRp ZmZlcmVudCBkZXNpZ24sIGJ1dCB0aGlzIFBSIHNob3VsZG4ndCBiZSBhYm91dCB0aGF0Lg0KPj4N Cj4+IEJhY2sgb24geW91ciAzIGl0ZW1zIDoNCj4+DQo+PiAxKSB5ZXMgd2UgY291bGQgbWFrZSBw cmUtcmVnaXN0ZXIgbWFuZGF0b3J5LCBidXQgd2UgYWxyZWFkeSBkZWNpZGVkIHRoYXQgd291bGRu J3QgYmUgaG93IHRoYXQgd291bGQgd29yay4gV2UgaGF2ZSBhIGNsaWVudCBpbnN0YW5jZSB0aGF0 IGFsbG93cyBhIG1vcmUgZ2VuZXJpYyBhbmQgZmxleGlibGUgcGF0dGVybiAod2hpY2ggQlRXIGFs c28gYWxsb3dzIHdoYXQgeW91IHdhbnQpDQo+Pg0KPj4gMikgaW5zdGVhZCBvZiBibGFtZSBhcmd1 bWVudHMgb2Ygd2hvJ3MgbGVzcyByZXN0ZnVsL0hBVEVPQVMvd2hhdGV2ZXIgdGhhdCBoYXZlIHRo ZSB0ZW5hbmN5IHRvIGZsYW1lIGNvbnZlcnNhdGlvbnMsIEkgc3VnZ2VzdCB3ZSBzcGVhayBpbiBs ZXNzIGFic3RyYWN0IHRlcm1zIGFuZCBhc2sgb3Vyc2VsdmVzIHdoYXQgdGhhdCBtZWFucyBpbiBw cmFjdGljZSBmb3IgZGV2cy4gU3RlcGhlbiBhbmQgc2V2ZXJhbCBvdGhlcnMgKG15c2VsZiBpbmNs dWRlZCkgaGF2ZSBleHByZXNzZWQgdGhhdCBpdCB3b3VsZG4ndCBiZSBoYXJkZXIgdG8gaW1wbGVt ZW50LCBpdCB3b3VsZCBldmVuIHNpbXBsaWZ5IHRoaW5ncyBxdWl0ZSBhIGxvdC4gSWYgeW91IGRp c2FncmVlIHBsZWFzZSBzZW5kIHVzIGEgY29kZSBzYW1wbGUgdG8gcmVhbGx5IHNob3cgdGhhdCBw b2ludCBieSBleGFtcGxlLCBiZWNhdXNlIHRoYXQncyByZWFsbHkgbm90IG9idmlvdXMuDQo+Pg0K Pj4gMykgIklmIHNvbWVvbmUgaGFzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMsIHRoZXkgY2FuIGlt cGVyc29uYXRlIHRoZSBjbGllbnQsIGFuZCBhbGwgYmV0cyBhcmUgb2ZmLiIgQXJlIHlvdSBzZXJp b3VzbHkgbWFraW5nIHRoaXMgYXJndW1lbnQ/IEJlY2F1c2UgaWYgeW91IGhhdmUgYSBiZXR0ZXIg cHJvcG9zYWwgdGhhbiB1c2luZyBjcnlwdG9ncmFwaGljIGtleXMsIEknbSBhbGwgaGVhcnMuIFlv dSBtYWtlIGl0IGxvb2sgbGlrZSB0aGVyZSdzIGEgcHJvYmxlbSwgd2hpbGUgaW4gcmVhbGl0eSB3 ZSdyZSBvbmx5IHJlbHlpbmcgb24gdGhlIGJhc2ljIGFzc3VtcHRpb24gb2YgYWxsIG1vZGVybiBk aWdpdGFsIGNvbW11bmljYXRpb25zLg0KPj4NCj4+IEFuZCBtb3JlIGltcG9ydGFudGx5IHlvdSBu ZXZlciByZXNwb25kZWQgdG8gdGhlIGlzc3VlcyBvZiBob3cgdG8gYXZvaWQgdGhlIHNlY3VyaXR5 IHBpdGZhbGxzIG9mIHdoYXQgeW91IHByb3Bvc2VkLg0KPj4NCj4+IEZhYmllbg0KPj4NCj4+DQo+ PiBMZSBzYW0uIDEyIGTDqWMuIDIwMjAgw6AgMDA6MzUsIERpY2sgSGFyZHQgPGRpY2suaGFyZHRA Z21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IGEgw6ljcml0IDoNCj4+DQo+ Pg0KPj4gT24gRnJpLCBEZWMgMTEsIDIwMjAgYXQgMjo1MyBQTSBTdGVwaGVuIE1vb3JlIDxzcm1v b3JlQGdtYWlsLmNvbTxtYWlsdG86c3Jtb29yZUBnbWFpbC5jb20+PiB3cm90ZToNCj4+IEJ1dCBm cm9tIHRoZSBzcGVjOg0KPj4gIg0KPj4gV2hlbiBzZW5kaW5nIGEgbm9uLWNvbnRpbnVhdGlvbiBy ZXF1ZXN0IHRvIHRoZSBBUywgdGhlIFJDIE1VU1QgaWRlbnRpZnkgaXRzZWxmIGJ5IGluY2x1ZGlu ZyB0aGUgY2xpZW50IGZpZWxkIG9mIHRoZSByZXF1ZXN0Li4uDQo+PiAuLi4NCj4+IGtleSAob2Jq ZWN0IC8gc3RyaW5nKSA6IFRoZSBwdWJsaWMga2V5IG9mIHRoZSBSQyB0byBiZSB1c2VkIGluIHRo aXMgcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4ge3tyZXF1ZXN0LWtleX19LiBUaGlzIGZpZWxkIGlz IFJFUVVJUkVELg0KPj4gLi4uDQo+PiAiDQo+PiBTbyBvbiB0aGUgaW5pdGlhbCByZXF1ZXN0LCB0 aGUga2V5IHdpbGwgYmUgdGhlcmUuDQo+Pg0KPj4gVGhlIGNsaWVudCBmaWVsZCBjYW4gYmUgYW4g b2JqZWN0IG9yIGEgc3RyaW5nLiBJZiB0aGUgY2xpZW50IGlzIHByZS1yZWdpc3RlcmVkLCB0aGVu IGEgc3RyaW5nIGNvdWxkIGJlIHByb3ZpZGVkIGluc3RlYWQgb2YgYW4gb2JqZWN0Lg0KPj4NCj4+ DQo+PiBJZiB5b3UgZG9uJ3QgaGF2ZSB0aGUgYWNjZXNzIHRva2VuLCB0aGVuIGhvdyBkbyB5b3Ug ZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHR3byByZXF1ZXN0cyBmcm9tIHRoZSBzYW1lIHdlYiBhcHBs aWNhdGlvbiBieSB0d28gZGlmZmVyZW50IHVzZXJzPyBJcyB0aGUgd2ViIGFwcGxpY2F0aW9uIHN1 cHBvc2VkIHRvIGhhdmUgZGlmZmVyZW50IGNyZWRlbnRpYWxzIGZvciBldmVyeSByZXF1ZXN0Pw0K Pj4NCj4+IFRoZSBBUyByZXR1cm5zIGEgVVJJIGZvciBtYW5pcHVsYXRpbmcgdGhlIHJlcXVlc3Qu IEkgd291bGQgY2hhbmdlIHRoZSBzcGVjIHNvIHRoYXQgZWFjaCByZXF1ZXN0IHdvdWxkIGhhdmUg YSB1bmlxdWUgVVJJLiBUaGlzIGlzIHRoZSB1c3VhbGx5IFJFU1RmdWwgcGF0dGVybiB0aGF0IHRo ZSByZXNvdXJjZSAodGhlIGdyYW50IHJlcXVlc3QpIGhhcyBhbiBVUkkuDQo+Pg0KPj4NCj4+IFNv IGluIHRoaXMgY2FzZSwgdGhlIGVhc3kgd2F5IG91dCBpcyB0byBwYXNzIHRoZSBhY2Nlc3MgdG9r ZW4gdG8gdGhlIGNsaWVudCwgd2hvIHRoZW4sIGFzIGkgc3RhdGVkIGJlZm9yZSwgdHJlYXRzIHRo ZSBjb250aW51ZSByZXF1ZXN0IGFzIGEgUlMgY2FsbCAoYWxiZWl0IGEgc3BlY2lhbGl6ZWQgdmVy c2lvbiBvZiB0aGUgUlMgd2hlcmUgdGhlIFJTIGlzIHRoZSBBUykgT1IgdG8gdXNlIHRoZSB1bmlx dWUgVVJMLA0KPj4gYnV0IHRoYXQgc2VlbXMgb3BlbiB0byBhIGJydXRlIGZvcmNlIGF0dGFjayBi eSBhIG1hbGljaW91cyBSQy4gKFdoYXQgd291bGQgYmUgdGhlIHBvaW50IG9mIHRoYXQgYXR0YWNr LCBJIGRvbid0IGtub3csIEkgZ3Vlc3MgaWYgc29tZW9uZSBoYWQgdGhlIGNsaWVudCBjcmVkZW50 aWFscyBidXQgbm90IGFueSBzdWJqZWN0cy9yZXNvdXJjZXMgdGhleSBjb3VsZCB0cnkgdG8gaW50 ZXJjZXB0IHRoZSBncmFudCB2aWEgY29udGludWUuLi4gSSBqdXN0IGRvbid0IGZlZWwgcmlnaHQg bG9ja2luZyB0aGluZ3MgZG93biB0byB1bmlxdWUgVVJMcyB0aGF0IHdheS4pDQo+Pg0KPj4gSWYg c29tZW9uZSBoYXMgdGhlIGNsaWVudCBjcmVkZW50aWFscywgdGhleSBjYW4gaW1wZXJzb25hdGUg dGhlIGNsaWVudCwgYW5kIGFsbCBiZXRzIGFyZSBvZmYuDQo+Pg0KPj4gTE9UUyBvZiBSUyBzZXJ2 ZXJzIHJldHVybiBhIHJlc291cmNlIHNwZWNpZmljIFVSTCAtLSBteSBwcm9wb3NhbCBpcyBubyBk aWZmZXJlbnQuDQo+Pg0KPj4NCj4+DQo+PiAtc3RldmUNCj4+DQo+PiBPbiBGcmksIERlYyAxMSwg MjAyMCBhdCA1OjMzIFBNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4gSGkgU3RlcGhlbg0KPj4NCj4+IFRoZSBj bGllbnQgaXMgc2lnbmluZyB0aGUgZmlyc3QgcmVxdWVzdC4gVGhlIGtleSAqbWlnaHQqIGJlIGlu IHRoZSBib2R5LiBUaGUgY2xpZW50IGlzIHNpZ25pbmcgYWxsIHRoZSBzdWJzZXF1ZW50IHJlcXVl c3RzIGFzIHdlbGwuIFRoZSAiYWNjZXNzIHRva2VuIiBpcyBub3QgbmVlZGVkIGJ5IHRoZSBjbGll bnQgdG8gcHJvdmUgaXQgaXMgYXV0aG9yaXplZCBhcyB0aGUgY2xpZW50IGlzIHByb3ZpbmcgaXQg aXMgdGhlIHNhbWUgY2xpZW50IGFnYWluLg0KPj4NCj4+IEluIG90aGVyIHdvcmRzLCBJIGRvbid0 IHNlZSB0aGUgbmVlZCBmb3IgYW4gYWNjZXNzIHRva2VuLCBzbyBpdCBkb2VzIG5vdCBuZWVkIHRv IGJlIHB1dCBpbiBhIFVSTCBvciBhbiBhdXRoIGhlYWRlci4NCj4+DQo+PiBJZiBhIGRldmVsb3Bl ciByZWFsbHksIHJlYWxseSB3YW50cyB0byBoYW5kIGNvbnRleHQgYmFjayB0byB0aGUgY2xpZW50 IGZvciBzdWJzZXF1ZW50IGNhbGxzLCB0aGV5IGNhbiBwdXQgaXQgaW4gdGhlIFVSTCBvciBzb21l IG90aGVyIG1ldGhvZC4gUHV0dGluZyBpdCBpbiB0aGUgSFRUUCBBdXRob3JpemF0aW9uIGhlYWRl ciBpcyBjb25mdXNpbmcgYmVjYXVzZSBpdCBpcyBOT1QgYW4gYWNjZXNzIHRva2VuIC0tIGl0IGlz IHRoZSBjb250ZXh0IG9mIHRoZSByZXF1ZXN0Lg0KPj4NCj4+IOGQpw0KPj4NCj4+IE9uIEZyaSwg RGVjIDExLCAyMDIwIGF0IDI6MDEgUE0gU3RlcGhlbiBNb29yZSA8c3Jtb29yZUBnbWFpbC5jb208 bWFpbHRvOnNybW9vcmVAZ21haWwuY29tPj4gd3JvdGU6DQo+PiBFdmVuIHRob3VnaCBJJ3ZlIG9u bHkgYmVlbiBsaWdodGx5IGZvbGxvd2luZyB0aGluZ3MsIEkgZmVlbCB0aGUgbmVlZCB0byB2b2lj ZSBteSBwcmVmZXJlbmNlIGFzIGEgZGV2ZWxvcGVyIHNpbmNlIEkgd2lsbCBwcm9iYWJseSBzb21l ZGF5IGhhdmUgdG8gZWl0aGVyIHdyaXRlIGEgUkMgb3IgUlMuLi4NCj4+DQo+PiBUaGUgd2F5IEkg c2VlIGl0IGlzIHRoZSBSQyBtYWtlcyB0aGUgaW5pdGlhbCByZXF1ZXN0IHRvIHRoZSBBUyBhcyBw YXJ0IG9mIHRoaXMgcmVxdWVzdCwgaXQgcHJvdmlkZXMgaXQncyBrZXkgaW4gdGhlIGJvZHkuLi4g KFNvIG5vIHVzZSBvZiB0aGUgQXV0aG9yaXphdGlvbiBoZWFkZXIpDQo+PiBBdCB0aGlzIHBvaW50 IHRoYXQgcmVxdWVzdCwgcmVwcmVzZW50ZWQgYnkgdGhlIGNvbnRpbnVlIFVSTCArICJBY2Nlc3Mg VG9rZW4iLCBmcm9tIG15IGxhenkgZGV2ZWxvcGVyIHN0YW5kcG9pbnQsIGlzIGEgUmVzb3VyY2Ug RW5kcG9pbnQgYW5kIEFjY2VzcyBUb2tlbiwgYW5kIHRoZSBBUyBpcyBhY3RpbmcgYXMgYSBzcGVj aWFsaXplZCBSUyBpbiB0aGlzIGNhc2UuDQo+PiBTbyBteSBjbGllbnQgcG9zdHMgdG8gd2hhdGV2 ZXIgVVJMIHdpdGggdGhlICdhY2Nlc3MgdG9rZW4nIGluIHRoZSBhdXRob3JpemF0aW9uIGhlYWRl ciwganVzdCBsaWtlIGFjdGluZyBvbiBhbnkgb3RoZXIgcmVzb3VyY2UgSSBoYXZlIGEgdG9rZW4g Zm9yLiBZRVMsIEkgZ2V0IGEgbmV3IHRva2VuIHZhbHVlIHRvIHVzZSBldmVyeSBjYWxsLCBhbmQg dGhlcmUgaXMgYSBkZWNpc2lvbiBwb2ludCBvZiAiRG8gSSBoYXZlIGFub3RoZXIgY29udGludWUs IG9yIGRvIEkgaGF2ZSBhIHJlYWwgdG9rZW4gZm9yIHRoZSByZXNvdXJjZS4uLiIgQnV0IHRoZSBt ZWNoYW5pc20gaXMgdGhlIHNhbWUgdG8gbWUgaW4gdGhlIGNsaWVudC4NCj4+IFBlcnNvbmFsbHkg SSBsaWtlIHRoYXQsIGJlY2F1c2UgaWYgSSBoYXZlIGFuIGFjY2Vzc190b2tlbiwgSSBhbHJlYWR5 IHRoaW5rICJQdXQgaXQgaW4gdGhlIGF1dGggaGVhZGVyLiINCj4+DQo+PiBTbyBteSB2b3RlIHdv dWxkIGJlICsxIGZvciB0aGUgcHVsbCByZXF1ZXN0IGF0IHRoaXMgdGltZS4NCj4+IC1zdGV2ZQ0K Pj4NCj4+IE9uIEZyaSwgRGVjIDExLCAyMDIwIGF0IDM6MDQgUE0gRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQo+PiBp bmxpbmUgLi4uDQo+Pg0KPj4gT24gRnJpLCBEZWMgMTEsIDIwMjAgYXQgOTo1OCBBTSBKdXN0aW4g UmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0K Pj4gT3RoZXJzIGhhZCBhbHJlYWR5IHJlc3BvbmRlZCB0byB0aGlzIHByZXZpb3VzIHRocmVhZCwg YnV0IEkgd2FudGVkIHRvIGFkZCBhIGNvdXBsZSBwb2ludHMgdG8gY2xhcmlmeSBzb21lIHRoaW5n cy4NCj4+DQo+Pj4gMykgV2hhdCB0aGUgY2xpZW50IGhhcyB0byBkbyB3aXRoIHRoZSAiYWNjZXNz IHRva2VuIiBpcyBub3QgdGhlIHNhbWUgYXMgYWNjZXNzIHRva2VucyBmb3IgYW4gUlMuIFRoZSBj bGllbnQgZ2V0cyBhIG5ldyAiYWNjZXNzIHRva2VuIiBmb3IgZWFjaCBncmFudCByZXF1ZXN0LCBh bmQgZm9yIGVhY2ggQVBJIGNhbGwgdG8gdGhlIEFTLCBhbmQgdGhlIGNsaWVudCBsZWFybnMgaXQg Y2FuIG5vdCBtYWtlIGFueSBtb3JlIEFQSSBjYWxscyBmb3IgdGhhdCBzcGVjaWZpYyByZXF1ZXN0 IHdoZW4gaXQgZG9lcyBub3QgZ2V0IGFuICJhY2Nlc3MgdG9rZW4iIGJhY2suIFRoaXMgaXMgYSBj b21wbGV0ZWx5IGRpZmZlcmVudCBkZXNpZ24gcGF0dGVybiB0aGFuIGNhbGxpbmcgYW4gUlMgQVBJ IHdpdGggYW4gYWNjZXNzIHRva2VuLCBhbmQgaXMgYSBuZXcgZGVzaWduIHBhdHRlcm4gZm9yIGNh bGxpbmcgQVBJcy4gVGhpcyBhZGRzIGNvbXBsZXhpdHkgdG8gdGhlIGNsaWVudCB0aGF0IGl0IHdv dWxkIG5vdCBub3JtYWxseSBoYXZlLCBhbmQgSSBkb24ndCB0aGluayBHTkFQIGlzIHRoZSByaWdo dCBwbGFjZSB0byBzdGFydCBhIG5ldyBkZXNpZ24gcGF0dGVybi4NCj4+Pg0KPj4NCj4+IEnigJlt IG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgdGhlc2UgYmVpbmcgZGlmZmVyZW50IOKAlCB0aGUg d2hvbGUgcG9pbnQgb2YgdGhlIGRlc2lnbiBpcyB0aGF0IHRoZSBjbGllbnQgd291bGQgYmUgZG9p bmcgdGhlIHNhbWUgdGhpbmcgd2l0aCB0aGUgYWNjZXNzIHRva2VuIGF0IHRoZSBBUyB0aGF0IGl0 IGRvZXMgd2l0aCB0aGUgUlMgYnkgcmUtdXNpbmcgdGhlIGFjY2VzcyB0b2tlbiBzdHJ1Y3R1cmUu IENhbiB5b3UgcGxlYXNlIGRlc2NyaWJlIHdoYXQgdGhlIGRpZmZlcmVuY2VzIGFyZSwgYXBhcnQg ZnJvbSB0aGUgcm90YXRpb24/IFByZXNlbnRhdGlvbiBvZiB0aGUgdG9rZW4gYW5kIHNpZ25pbmcg b2YgdGhlIG1lc3NhZ2UgYXJlIGlkZW50aWNhbC4NCj4+DQo+PiBUaGUgY2xpZW50IGlzIGdldHRp bmcgdGhlICJhY2Nlc3MgdG9rZW4iIGZyb20gaXRzIEFQSS4gSXQgaXMgbm90IHVzaW5nIGFuICJh Y2Nlc3NfdG9rZW4iIGluIG90aGVyIEFQSSBjYWxscyB0byB0aGUgQVMuDQo+Pg0KPj4NCj4+IFJv dGF0aW9uIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYW5kIGFydGlmYWN0cyBmb3Igb25nb2luZyBjb250 aW51YXRpb24gcmVzcG9uc2VzIGlzIGEgc2VwYXJhdGUgaXNzdWUgdG8gYmUgZGlzY3Vzc2VkOiBo dHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2duYXAtY29yZS1wcm90b2NvbC9pc3N1ZXMv ODcNCj4+DQo+PiBBbmQgZm9yIHdoYXQgaXTigJlzIHdvcnRoLCBHTkFQIGlzIGFic29sdXRlbHkg dGhlIHJpZ2h0IHBsYWNlIHRvIGhhdmUgbmV3IGRlc2lnbnMg4oCUIG5vdCB0aGF0IHRoaXMgaXMg b25lLg0KPj4NCj4+IFlvdSBhcmUgcHJvcG9zaW5nIGEgbmV3IHdheSBmb3IgYW4gQVBJIHRvIHBy b3ZpZGUgY29udGV4dCBmb3Igc3Vic2VxdWVudCBBUEkgY2FsbHMuIExvb2tzIG91dCBvZiBzY29w ZSB0byBtZS4NCj4+DQo+Pg0KPj4+IDQpIENsaWVudHMgdGhhdCBvbmx5IHdhbnQgY2xhaW1zIGZy b20gdGhlIEFTIGFuZCBubyBhY2Nlc3MgdG9rZW5zIHdpbGwgYmUgcmVxdWlyZWQgdG8gc3VwcG9y dCBhbiBBUEkgY2FsbGluZyBtZWNoYW5pc20gdGhleSB3b3VsZCBub3QgaGF2ZSB0byBzdXBwb3J0 IG90aGVyd2lzZS4NCj4+DQo+PiBDb3JyZWN0LCBidXQgdGhlIGRlbHRhIGJldHdlZW4gdGhlIGNh bGxzIGEgY2xpZW50IHdvdWxkIG1ha2Ugd2l0aCBhbmQgd2l0aG91dCBhbiBhY2Nlc3MgdG9rZW4g aXMgdmFuaXNoaW5nbHkgc21hbGwuIFRoZSBjbGllbnQgaGFzIHRvIHNpZ24gdGhlIGluaXRpYWwg cmVxdWVzdCBpbiBzb21lIGZhc2hpb24sIGFuZCBpdCB3aWxsIHNpZ24gdGhlIGNvbnRpbnVhdGlv biByZXF1ZXN0IGluIHRoZSBzYW1lIGV4YWN0IGZhc2hpb24sIGJ1dCBub3cgaW5jbHVkZSBhbiBh Y2Nlc3MgdG9rZW4gaW4gdGhhdCByZXF1ZXN0Lg0KPj4NCj4+IFBlciBteSBvdGhlciBwb2ludCwg dGhlcmUgaXMgbm8gdmFsdWUgdG8gbWUgaW4gbXkgaW1wbGVtZW50YXRpb25zIG9mIHBhc3Npbmcg Y29udGV4dCBiYWNrIGFuZCBmb3J0aCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIEFTIC0tIHNvIGl0 IGlzIGV4dHJhIHdvcmsgcHJvdmlkaW5nIG5vIHZhbHVlLg0KPj4NCj4+IEFsc28sIGFueSBjbGll bnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIHRoYXQgd2FudHMgdG8gdXNlIHRoZSBIVFRQIEF1 dGhlbnRpY2F0aW9uIGhlYWRlciBpcyBwcmVjbHVkZWQgZnJvbSB1c2luZyBpdC4NCj4+DQo+Pg0K Pj4NCj4+IENsaWVudHMgbWFraW5nIGEgcmVxdWVzdCB0byBhbiBBUyBhbmQgbm90IGdldHRpbmcg YW4gYWNjZXNzIHRva2VuIGlzIGEgbmV3IGRlc2lnbiBwYXR0ZXJuLiBJIHRoaW5rIGl0IGhhcyB2 YWx1ZSBhbmQgc2hvdWxkIGJlIGluY2x1ZGVkLCBidXQgT0F1dGggdG9kYXkgc2hvd3MgdXMgdGhl IGltbWVuc2UgdmFsdWUgb2YgZ2V0dGluZyBhY2Nlc3MgdG9rZW5zIGZvciBjYWxsaW5nIEFQSXMs IGFuZCBzbyB3ZSBzaG91bGRu4oCZdCBvcHRpbWl6ZSBhd2F5IGZyb20gdGhhdCBwYXR0ZXJuLg0K Pj4NCj4+Pg0KPj4+IDUpIElmIHRoZSBBUyBkb2VzIG5vdCBwcm92aWRlIGFuICJhY2Nlc3MgdG9r ZW4iLCB0aGVyZSBpcyBubyBtZWNoYW5pc20gZm9yIGEgY2xpZW50IHRvIGRlbGV0ZSB0aGUgcmVx dWVzdCwgYXMgdGhlIGNsaWVudCBpcyBub3QgYWxsb3dlZCB0byBtYWtlIGEgY2FsbCB3aXRob3V0 IGFuICJhY2Nlc3MgdG9rZW4iLg0KPj4NCj4+IE1vcmUgcHJvcGVybHksIGlmIHRoZSBBUyBkb2Vz IG5vdCBwcm92aWRlIGEg4oCcY29udGludWXigJ0gZmllbGQgdGhlbiB0aGUgY2xpZW50IGNhbuKA mXQgZGVsZXRlIHRoZSByZXF1ZXN0IOKAlCBhbmQgeWVzLCB0aGF04oCZcyBpbnRlbnRpb25hbC4g VGhlIEFTIGlzIHRlbGxpbmcgdGhpcyBjbGllbnQgaW5zdGFuY2UgdGhhdCBpdCBjYW7igJl0IGRv IGFueXRoaW5nIGVsc2Ugd2l0aCB0aGlzIG9uZ29pbmcgcmVxdWVzdC4gSWYgdGhlIEFTIHdhbnRz IHRvIGFsbG93IHRoZSBjbGllbnQgdG8gbWFuYWdlIGl0LCBpdCB3aWxsIGluY2x1ZGUgdGhlIG1l Y2hhbmlzbXMgdG8gZG8gc28gaW4gdGhlIOKAnGNvbnRpbnVl4oCdIGZpZWxkLg0KPj4NCj4+IFRo ZXJlIGlzIG51YW5jZSBpbiB0aGF0IGludGVudGlvbi4gQSByZWxhdGVkIGNvbmNlcm4gaXMgdGhh dCBkZWxldGluZyBhIHJlcXVlc3QgZG9lcyBub3Qgc2VlbSBsaWtlIGl0IGlzIGEgImNvbnRpbnVl IiBvcGVyYXRpb24uDQo+Pg0KPj4NCj4+Pg0KPj4+IDYpIFRoZXJlIGlzIG5vIHN0YW5kYXJkIGlk ZW50aWZpZXIgZm9yIHRoZSByZXF1ZXN0LiBEZWJ1Z2dpbmcgYW5kIGF1ZGl0aW5nIGFyZSBoYW1w ZXJlZCBieSB0aGUgY2xpZW50IGFuZCBBUyBoYXZpbmcgbm8gc3RhbmRhcmQgd2F5IHRvIGlkZW50 aWZ5aW5nIGEgcmVxdWVzdC4gV2hpbGUgb25lIEFTIG1heSBwcm92aWRlIGEgdW5pcXVlIFVSTCBm b3IgZWFjaCBncmFudCByZXF1ZXN0LCBhbm90aGVyIEFTIG1heSB1c2UgYSBwZXJzaXN0ZW50ICJh Y2Nlc3MgdG9rZW4iIHRvIGlkZW50aWZ5IHRoZSBncmFudCByZXF1ZXN0LCBhbmQgb3RoZXIgQVNz IG1heSBpc3N1ZSBhIG5ldyAiYWNjZXNzIHRva2VuIiBvbiBlYWNoIEFQSSBjYWxsLCBwcm92aWRp bmcgbm8gcGVyc2lzdGVudCBpZGVudGlmaWVyIGZvciB0aGUgcmVxdWVzdC4NCj4+DQo+PiBEZWJ1 Z2dpbmcgYW5kIGF1ZGl0aW5nIHRoaXMga2luZCBvZiB0aGluZyBhcmUgZnVuY3Rpb25zIG9mIHRo ZSBBUy4gSG93IGlzIGludGVyb3BlcmFiaWxpdHkgaGFybWVkIGJ5IGRpZmZlcmVudCBBU3MgaGF2 aW5nIGRpZmZlcmVudCBtZXRob2RzIHRvIGlkZW50aWZ5IHRoZWlyIGludGVybmFsIGRhdGEgZWxl bWVudHM/IFRoZSBjbGllbnQgZG9lc27igJl0IG5lZWQgYW55IGtub3dsZWRnZSBvZiB0aGUgQVPi gJlzIGlkZW50aWZpZXJzLCBpdCBqdXN0IG5lZWRzIHRvIGtub3cgdGhlIG5leHQgc3RlcHMgZm9y IGNvbnRpbnVpbmcgdGhlIG5lZ290aWF0aW9uLg0KPj4NCj4+IERlYnVnZ2luZyBiZXR3ZWVuIHRo ZSBjbGllbnQgYW5kIHRoZSBBUyB3YXMgd2hhdCBJIHdhcyByZWZlcnJpbmcgdG8uIEhvdyBkb2Vz IGEgY2xpZW50IGRldmVsb3BlciBpZGVudGlmeSB0aGUgcmVxdWVzdCB3aGVuIGNvbW11bmljYXRp bmcgdG8gdGhlIEFTIGRldmVsb3Blci4gU2VlbXMgY29tcGxpY2F0ZWQuDQo+Pg0KPj4g4ZCnDQo+ PiAtLQ0KPj4gVFhBdXRoIG1haWxpbmcgbGlzdA0KPj4gVFhBdXRoQGlldGYub3JnPG1haWx0bzpU WEF1dGhAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aA0KPj4g4ZCnDQo+PiAtLQ0KPj4gVFhBdXRoIG1haWxpbmcgbGlzdA0KPj4gVFhBdXRo QGlldGYub3JnPG1haWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KPj4gLS0NCj4+IFRYQXV0aCBtYWlsaW5nIGxpc3QN Cj4+IFRYQXV0aEBpZXRmLm9yZzxtYWlsdG86VFhBdXRoQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93 d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aCZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYwODM0NTMyMDAwMDAwMCZ1c2c9QU92VmF3 MHIzOWxINHFWT3UwSVFQSkpZdFNwSQ0KDQotLQ0KVFhBdXRoIG1haWxpbmcgbGlzdA0KVFhBdXRo QGlldGYub3JnPG1haWx0bzpUWEF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQoNCi0tDQpEYXZlIFRvbmdlDQpDVE8NCltNb25leWh1 YiBFbnRlcnByaXNlXTxodHRwOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cCUzQSUyRiUyRm1v bmV5aHViZW50ZXJwcmlzZS5jb20lMkYmc2E9RCZzbnR6PTEmdXNnPUFGUWpDTkdVblI1b3BKdjVT MXVaT1ZnOGFJU3dQS0F2M0E+DQpNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSwgNXRoIEZs b29yLCAxMCBUZW1wbGUgQmFjaywgQnJpc3RvbCwgQlMxIDZGTA0KdDogKzQ0ICgwKTExNyAyODAg NTEyMA0KDQpNb25leWh1YiBFbnRlcnByaXNlIGlzIGEgdHJhZGluZyBzdHlsZSBvZiBNb25leWh1 YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBMaW1pdGVkIHdoaWNoIGlzIGF1dGhvcmlzZWQgYW5kIHJl Z3VsYXRlZCBieSB0aGUgRmluYW5jaWFsIENvbmR1Y3QgQXV0aG9yaXR5ICgiRkNBIikuIE1vbmV5 aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IGlzIGVudGVyZWQgb24gdGhlIEZpbmFuY2lhbCBTZXJ2 aWNlcyBSZWdpc3RlciAoRlJOIDgwOTM2MCkgYXQgaHR0cHM6Ly9yZWdpc3Rlci5mY2Eub3JnLnVr Ly4gTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgaXMgcmVnaXN0ZXJlZCBpbiBFbmdsYW5k ICYgV2FsZXMsIGNvbXBhbnkgcmVnaXN0cmF0aW9uIG51bWJlciAgMDY5MDk3NzIgLg0KTW9uZXlo dWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgTGltaXRlZCAyMDE5IMKpDQoNCkRJU0NMQUlNRVI6IFRo aXMgZW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIHN1YmplY3QgdG8gY29weXJp Z2h0LCBhbmQgdGhlIGluZm9ybWF0aW9uIGluIGl0IGlzIGNvbmZpZGVudGlhbC4gVXNlIG9mIHRo aXMgZW1haWwgb3Igb2YgYW55IGluZm9ybWF0aW9uIGluIGl0IG90aGVyIHRoYW4gYnkgdGhlIGFk ZHJlc3NlZSBpcyB1bmF1dGhvcmlzZWQgYW5kIHVubGF3ZnVsLiBXaGlsc3QgcmVhc29uYWJsZSBl ZmZvcnRzIGFyZSBtYWRlIHRvIGVuc3VyZSB0aGF0IGFueSBhdHRhY2htZW50cyBhcmUgdmlydXMt ZnJlZSwgaXQgaXMgdGhlIHJlY2lwaWVudCdzIHNvbGUgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBh bGwgYXR0YWNobWVudHMgZm9yIHZpcnVzZXMuIEFsbCBjYWxscyBhbmQgZW1haWxzIHRvIGFuZCBm cm9tIHRoaXMgY29tcGFueSBtYXkgYmUgbW9uaXRvcmVkIGFuZCByZWNvcmRlZCBmb3IgbGVnaXRp bWF0ZSBwdXJwb3NlcyByZWxhdGluZyB0byB0aGlzIGNvbXBhbnkncyBidXNpbmVzcy4gQW55IG9w aW5pb25zIGV4cHJlc3NlZCBpbiB0aGlzIGVtYWlsIChvciBpbiBhbnkgYXR0YWNobWVudHMpIGFy ZSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRo ZSBvcGluaW9ucyBvZiBNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBMaW1pdGVkIG9yIG9m IGFueSBvdGhlciBncm91cCBjb21wYW55Lg0KDQoNCk1vbmV5aHViIEVudGVycHJpc2UgaXMgYSB0 cmFkaW5nIHN0eWxlIG9mIE1vbmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IExpbWl0ZWQgd2hp Y2ggaXMgYXV0aG9yaXNlZCBhbmQgcmVndWxhdGVkIGJ5IHRoZSBGaW5hbmNpYWwgQ29uZHVjdCBB dXRob3JpdHkgKCJGQ0EiKS4gTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgaXMgZW50ZXJl ZCBvbiB0aGUgRmluYW5jaWFsIFNlcnZpY2VzIFJlZ2lzdGVyIChGUk4gODA5MzYwKSBhdCBodHRw czovL3JlZ2lzdGVyLmZjYS5vcmcudWsvLiBNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBp cyByZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcywgY29tcGFueSByZWdpc3RyYXRpb24gbnVt YmVyIDA2OTA5NzcyLiBNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBMaW1pdGVkIDIwMjAg wqkgTW9uZXlodWIgRW50ZXJwcmlzZSwgUmVndXMgQnVpbGRpbmcsIFRlbXBsZSBRdWF5LCAxIEZy aWFyeSwgQnJpc3RvbCwgQlMxIDZFQS4NCg0KRElTQ0xBSU1FUjogVGhpcyBlbWFpbCAoaW5jbHVk aW5nIGFueSBhdHRhY2htZW50cykgaXMgc3ViamVjdCB0byBjb3B5cmlnaHQsIGFuZCB0aGUgaW5m b3JtYXRpb24gaW4gaXQgaXMgY29uZmlkZW50aWFsLiBVc2Ugb2YgdGhpcyBlbWFpbCBvciBvZiBh bnkgaW5mb3JtYXRpb24gaW4gaXQgb3RoZXIgdGhhbiBieSB0aGUgYWRkcmVzc2VlIGlzIHVuYXV0 aG9yaXNlZCBhbmQgdW5sYXdmdWwuIFdoaWxzdCByZWFzb25hYmxlIGVmZm9ydHMgYXJlIG1hZGUg dG8gZW5zdXJlIHRoYXQgYW55IGF0dGFjaG1lbnRzIGFyZSB2aXJ1cy1mcmVlLCBpdCBpcyB0aGUg cmVjaXBpZW50J3Mgc29sZSByZXNwb25zaWJpbGl0eSB0byBzY2FuIGFsbCBhdHRhY2htZW50cyBm b3IgdmlydXNlcy4gQWxsIGNhbGxzIGFuZCBlbWFpbHMgdG8gYW5kIGZyb20gdGhpcyBjb21wYW55 IG1heSBiZSBtb25pdG9yZWQgYW5kIHJlY29yZGVkIGZvciBsZWdpdGltYXRlIHB1cnBvc2VzIHJl bGF0aW5nIHRvIHRoaXMgY29tcGFueSdzIGJ1c2luZXNzLiBBbnkgb3BpbmlvbnMgZXhwcmVzc2Vk IGluIHRoaXMgZW1haWwgKG9yIGluIGFueSBhdHRhY2htZW50cykgYXJlIHRob3NlIG9mIHRoZSBh dXRob3IgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIG9waW5pb25zIG9mIE1v bmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IExpbWl0ZWQgb3Igb2YgYW55IG90aGVyIGdyb3Vw IGNvbXBhbnkuDQoNCg0KDQotLQ0KRGF2ZSBUb25nZQ0KQ1RPDQpbTW9uZXlodWIgRW50ZXJwcmlz ZV08aHR0cDovL3d3dy5nb29nbGUuY29tL3VybD9xPWh0dHAlM0ElMkYlMkZtb25leWh1YmVudGVy cHJpc2UuY29tJTJGJnNhPUQmc250ej0xJnVzZz1BRlFqQ05HVW5SNW9wSnY1UzF1Wk9WZzhhSVN3 UEtBdjNBPg0KTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3ksIDV0aCBGbG9vciwgMTAgVGVt cGxlIEJhY2ssIEJyaXN0b2wsIEJTMSA2RkwNCnQ6ICs0NCAoMCkxMTcgMjgwIDUxMjANCg0KTW9u ZXlodWIgRW50ZXJwcmlzZSBpcyBhIHRyYWRpbmcgc3R5bGUgb2YgTW9uZXlodWIgRmluYW5jaWFs IFRlY2hub2xvZ3kgTGltaXRlZCB3aGljaCBpcyBhdXRob3Jpc2VkIGFuZCByZWd1bGF0ZWQgYnkg dGhlIEZpbmFuY2lhbCBDb25kdWN0IEF1dGhvcml0eSAoIkZDQSIpLiBNb25leWh1YiBGaW5hbmNp YWwgVGVjaG5vbG9neSBpcyBlbnRlcmVkIG9uIHRoZSBGaW5hbmNpYWwgU2VydmljZXMgUmVnaXN0 ZXIgKEZSTiA4MDkzNjApIGF0IGh0dHBzOi8vcmVnaXN0ZXIuZmNhLm9yZy51ay8uIE1vbmV5aHVi IEZpbmFuY2lhbCBUZWNobm9sb2d5IGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzLCBj b21wYW55IHJlZ2lzdHJhdGlvbiBudW1iZXIgIDA2OTA5NzcyIC4NCk1vbmV5aHViIEZpbmFuY2lh bCBUZWNobm9sb2d5IExpbWl0ZWQgMjAxOSDCqQ0KDQpESVNDTEFJTUVSOiBUaGlzIGVtYWlsIChp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBzdWJqZWN0IHRvIGNvcHlyaWdodCwgYW5kIHRo ZSBpbmZvcm1hdGlvbiBpbiBpdCBpcyBjb25maWRlbnRpYWwuIFVzZSBvZiB0aGlzIGVtYWlsIG9y IG9mIGFueSBpbmZvcm1hdGlvbiBpbiBpdCBvdGhlciB0aGFuIGJ5IHRoZSBhZGRyZXNzZWUgaXMg dW5hdXRob3Jpc2VkIGFuZCB1bmxhd2Z1bC4gV2hpbHN0IHJlYXNvbmFibGUgZWZmb3J0cyBhcmUg bWFkZSB0byBlbnN1cmUgdGhhdCBhbnkgYXR0YWNobWVudHMgYXJlIHZpcnVzLWZyZWUsIGl0IGlz IHRoZSByZWNpcGllbnQncyBzb2xlIHJlc3BvbnNpYmlsaXR5IHRvIHNjYW4gYWxsIGF0dGFjaG1l bnRzIGZvciB2aXJ1c2VzLiBBbGwgY2FsbHMgYW5kIGVtYWlscyB0byBhbmQgZnJvbSB0aGlzIGNv bXBhbnkgbWF5IGJlIG1vbml0b3JlZCBhbmQgcmVjb3JkZWQgZm9yIGxlZ2l0aW1hdGUgcHVycG9z ZXMgcmVsYXRpbmcgdG8gdGhpcyBjb21wYW55J3MgYnVzaW5lc3MuIEFueSBvcGluaW9ucyBleHBy ZXNzZWQgaW4gdGhpcyBlbWFpbCAob3IgaW4gYW55IGF0dGFjaG1lbnRzKSBhcmUgdGhvc2Ugb2Yg dGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgb3BpbmlvbnMg b2YgTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgTGltaXRlZCBvciBvZiBhbnkgb3RoZXIg Z3JvdXAgY29tcGFueS4NCg0KDQpNb25leWh1YiBFbnRlcnByaXNlIGlzIGEgdHJhZGluZyBzdHls ZSBvZiBNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBMaW1pdGVkIHdoaWNoIGlzIGF1dGhv cmlzZWQgYW5kIHJlZ3VsYXRlZCBieSB0aGUgRmluYW5jaWFsIENvbmR1Y3QgQXV0aG9yaXR5ICgi RkNBIikuIE1vbmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IGlzIGVudGVyZWQgb24gdGhlIEZp bmFuY2lhbCBTZXJ2aWNlcyBSZWdpc3RlciAoRlJOIDgwOTM2MCkgYXQgaHR0cHM6Ly9yZWdpc3Rl ci5mY2Eub3JnLnVrLy4gTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgaXMgcmVnaXN0ZXJl ZCBpbiBFbmdsYW5kICYgV2FsZXMsIGNvbXBhbnkgcmVnaXN0cmF0aW9uIG51bWJlciAwNjkwOTc3 Mi4gTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgTGltaXRlZCAyMDIwIMKpIE1vbmV5aHVi IEVudGVycHJpc2UsIFJlZ3VzIEJ1aWxkaW5nLCBUZW1wbGUgUXVheSwgMSBGcmlhcnksIEJyaXN0 b2wsIEJTMSA2RUEuDQoNCkRJU0NMQUlNRVI6IFRoaXMgZW1haWwgKGluY2x1ZGluZyBhbnkgYXR0 YWNobWVudHMpIGlzIHN1YmplY3QgdG8gY29weXJpZ2h0LCBhbmQgdGhlIGluZm9ybWF0aW9uIGlu IGl0IGlzIGNvbmZpZGVudGlhbC4gVXNlIG9mIHRoaXMgZW1haWwgb3Igb2YgYW55IGluZm9ybWF0 aW9uIGluIGl0IG90aGVyIHRoYW4gYnkgdGhlIGFkZHJlc3NlZSBpcyB1bmF1dGhvcmlzZWQgYW5k IHVubGF3ZnVsLiBXaGlsc3QgcmVhc29uYWJsZSBlZmZvcnRzIGFyZSBtYWRlIHRvIGVuc3VyZSB0 aGF0IGFueSBhdHRhY2htZW50cyBhcmUgdmlydXMtZnJlZSwgaXQgaXMgdGhlIHJlY2lwaWVudCdz IHNvbGUgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBhbGwgYXR0YWNobWVudHMgZm9yIHZpcnVzZXMu IEFsbCBjYWxscyBhbmQgZW1haWxzIHRvIGFuZCBmcm9tIHRoaXMgY29tcGFueSBtYXkgYmUgbW9u aXRvcmVkIGFuZCByZWNvcmRlZCBmb3IgbGVnaXRpbWF0ZSBwdXJwb3NlcyByZWxhdGluZyB0byB0 aGlzIGNvbXBhbnkncyBidXNpbmVzcy4gQW55IG9waW5pb25zIGV4cHJlc3NlZCBpbiB0aGlzIGVt YWlsIChvciBpbiBhbnkgYXR0YWNobWVudHMpIGFyZSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBk byBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSBvcGluaW9ucyBvZiBNb25leWh1YiBGaW5h bmNpYWwgVGVjaG5vbG9neSBMaW1pdGVkIG9yIG9mIGFueSBvdGhlciBncm91cCBjb21wYW55Lg0K DQoNCi0tDQpUWEF1dGggbWFpbGluZyBsaXN0DQpUWEF1dGhAaWV0Zi5vcmc8bWFpbHRvOlRYQXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRo DQoNCg0KLS0NCkRhdmUgVG9uZ2UNCkNUTw0KW01vbmV5aHViIEVudGVycHJpc2VdPGh0dHA6Ly93 d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwJTNBJTJGJTJGbW9uZXlodWJlbnRlcnByaXNlLmNvbSUy RiZzYT1EJnNudHo9MSZ1c2c9QUZRakNOR1VuUjVvcEp2NVMxdVpPVmc4YUlTd1BLQXYzQT4NCk1v bmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5LCA1dGggRmxvb3IsIDEwIFRlbXBsZSBCYWNrLCBC cmlzdG9sLCBCUzEgNkZMDQp0OiArNDQgKDApMTE3IDI4MCA1MTIwDQoNCk1vbmV5aHViIEVudGVy cHJpc2UgaXMgYSB0cmFkaW5nIHN0eWxlIG9mIE1vbmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5 IExpbWl0ZWQgd2hpY2ggaXMgYXV0aG9yaXNlZCBhbmQgcmVndWxhdGVkIGJ5IHRoZSBGaW5hbmNp YWwgQ29uZHVjdCBBdXRob3JpdHkgKCJGQ0EiKS4gTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xv Z3kgaXMgZW50ZXJlZCBvbiB0aGUgRmluYW5jaWFsIFNlcnZpY2VzIFJlZ2lzdGVyIChGUk4gODA5 MzYwKSBhdCBodHRwczovL3JlZ2lzdGVyLmZjYS5vcmcudWsvLiBNb25leWh1YiBGaW5hbmNpYWwg VGVjaG5vbG9neSBpcyByZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcywgY29tcGFueSByZWdp c3RyYXRpb24gbnVtYmVyICAwNjkwOTc3MiAuDQpNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9n eSBMaW1pdGVkIDIwMTkgwqkNCg0KRElTQ0xBSU1FUjogVGhpcyBlbWFpbCAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgaXMgc3ViamVjdCB0byBjb3B5cmlnaHQsIGFuZCB0aGUgaW5mb3JtYXRp b24gaW4gaXQgaXMgY29uZmlkZW50aWFsLiBVc2Ugb2YgdGhpcyBlbWFpbCBvciBvZiBhbnkgaW5m b3JtYXRpb24gaW4gaXQgb3RoZXIgdGhhbiBieSB0aGUgYWRkcmVzc2VlIGlzIHVuYXV0aG9yaXNl ZCBhbmQgdW5sYXdmdWwuIFdoaWxzdCByZWFzb25hYmxlIGVmZm9ydHMgYXJlIG1hZGUgdG8gZW5z dXJlIHRoYXQgYW55IGF0dGFjaG1lbnRzIGFyZSB2aXJ1cy1mcmVlLCBpdCBpcyB0aGUgcmVjaXBp ZW50J3Mgc29sZSByZXNwb25zaWJpbGl0eSB0byBzY2FuIGFsbCBhdHRhY2htZW50cyBmb3Igdmly dXNlcy4gQWxsIGNhbGxzIGFuZCBlbWFpbHMgdG8gYW5kIGZyb20gdGhpcyBjb21wYW55IG1heSBi ZSBtb25pdG9yZWQgYW5kIHJlY29yZGVkIGZvciBsZWdpdGltYXRlIHB1cnBvc2VzIHJlbGF0aW5n IHRvIHRoaXMgY29tcGFueSdzIGJ1c2luZXNzLiBBbnkgb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRo aXMgZW1haWwgKG9yIGluIGFueSBhdHRhY2htZW50cykgYXJlIHRob3NlIG9mIHRoZSBhdXRob3Ig YW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIG9waW5pb25zIG9mIE1vbmV5aHVi IEZpbmFuY2lhbCBUZWNobm9sb2d5IExpbWl0ZWQgb3Igb2YgYW55IG90aGVyIGdyb3VwIGNvbXBh bnkuDQoNCg0KTW9uZXlodWIgRW50ZXJwcmlzZSBpcyBhIHRyYWRpbmcgc3R5bGUgb2YgTW9uZXlo dWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgTGltaXRlZCB3aGljaCBpcyBhdXRob3Jpc2VkIGFuZCBy ZWd1bGF0ZWQgYnkgdGhlIEZpbmFuY2lhbCBDb25kdWN0IEF1dGhvcml0eSAoIkZDQSIpLiBNb25l eWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBpcyBlbnRlcmVkIG9uIHRoZSBGaW5hbmNpYWwgU2Vy dmljZXMgUmVnaXN0ZXIgKEZSTiA4MDkzNjApIGF0IGh0dHBzOi8vcmVnaXN0ZXIuZmNhLm9yZy51 ay8uIE1vbmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAmIFdhbGVzLCBjb21wYW55IHJlZ2lzdHJhdGlvbiBudW1iZXIgMDY5MDk3NzIuIE1vbmV5aHVi IEZpbmFuY2lhbCBUZWNobm9sb2d5IExpbWl0ZWQgMjAyMCDCqSBNb25leWh1YiBFbnRlcnByaXNl LCBSZWd1cyBCdWlsZGluZywgVGVtcGxlIFF1YXksIDEgRnJpYXJ5LCBCcmlzdG9sLCBCUzEgNkVB Lg0KDQpESVNDTEFJTUVSOiBUaGlzIGVtYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBp cyBzdWJqZWN0IHRvIGNvcHlyaWdodCwgYW5kIHRoZSBpbmZvcm1hdGlvbiBpbiBpdCBpcyBjb25m aWRlbnRpYWwuIFVzZSBvZiB0aGlzIGVtYWlsIG9yIG9mIGFueSBpbmZvcm1hdGlvbiBpbiBpdCBv dGhlciB0aGFuIGJ5IHRoZSBhZGRyZXNzZWUgaXMgdW5hdXRob3Jpc2VkIGFuZCB1bmxhd2Z1bC4g V2hpbHN0IHJlYXNvbmFibGUgZWZmb3J0cyBhcmUgbWFkZSB0byBlbnN1cmUgdGhhdCBhbnkgYXR0 YWNobWVudHMgYXJlIHZpcnVzLWZyZWUsIGl0IGlzIHRoZSByZWNpcGllbnQncyBzb2xlIHJlc3Bv bnNpYmlsaXR5IHRvIHNjYW4gYWxsIGF0dGFjaG1lbnRzIGZvciB2aXJ1c2VzLiBBbGwgY2FsbHMg YW5kIGVtYWlscyB0byBhbmQgZnJvbSB0aGlzIGNvbXBhbnkgbWF5IGJlIG1vbml0b3JlZCBhbmQg cmVjb3JkZWQgZm9yIGxlZ2l0aW1hdGUgcHVycG9zZXMgcmVsYXRpbmcgdG8gdGhpcyBjb21wYW55 J3MgYnVzaW5lc3MuIEFueSBvcGluaW9ucyBleHByZXNzZWQgaW4gdGhpcyBlbWFpbCAob3IgaW4g YW55IGF0dGFjaG1lbnRzKSBhcmUgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vz c2FyaWx5IHJlcHJlc2VudCB0aGUgb3BpbmlvbnMgb2YgTW9uZXlodWIgRmluYW5jaWFsIFRlY2hu b2xvZ3kgTGltaXRlZCBvciBvZiBhbnkgb3RoZXIgZ3JvdXAgY29tcGFueS4NCg0KDQoNCg0KLS0N CkRhdmUgVG9uZ2UNCkNUTw0KW01vbmV5aHViIEVudGVycHJpc2VdPGh0dHA6Ly93d3cuZ29vZ2xl LmNvbS91cmw/cT1odHRwJTNBJTJGJTJGbW9uZXlodWJlbnRlcnByaXNlLmNvbSUyRiZzYT1EJnNu dHo9MSZ1c2c9QUZRakNOR1VuUjVvcEp2NVMxdVpPVmc4YUlTd1BLQXYzQT4NCk1vbmV5aHViIEZp bmFuY2lhbCBUZWNobm9sb2d5LCA1dGggRmxvb3IsIDEwIFRlbXBsZSBCYWNrLCBCcmlzdG9sLCBC UzEgNkZMDQp0OiArNDQgKDApMTE3IDI4MCA1MTIwDQoNCk1vbmV5aHViIEVudGVycHJpc2UgaXMg YSB0cmFkaW5nIHN0eWxlIG9mIE1vbmV5aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IExpbWl0ZWQg d2hpY2ggaXMgYXV0aG9yaXNlZCBhbmQgcmVndWxhdGVkIGJ5IHRoZSBGaW5hbmNpYWwgQ29uZHVj dCBBdXRob3JpdHkgKCJGQ0EiKS4gTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgaXMgZW50 ZXJlZCBvbiB0aGUgRmluYW5jaWFsIFNlcnZpY2VzIFJlZ2lzdGVyIChGUk4gODA5MzYwKSBhdCBo dHRwczovL3JlZ2lzdGVyLmZjYS5vcmcudWsvLiBNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9n eSBpcyByZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcywgY29tcGFueSByZWdpc3RyYXRpb24g bnVtYmVyICAwNjkwOTc3MiAuDQpNb25leWh1YiBGaW5hbmNpYWwgVGVjaG5vbG9neSBMaW1pdGVk IDIwMTkgwqkNCg0KRElTQ0xBSU1FUjogVGhpcyBlbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cykgaXMgc3ViamVjdCB0byBjb3B5cmlnaHQsIGFuZCB0aGUgaW5mb3JtYXRpb24gaW4gaXQg aXMgY29uZmlkZW50aWFsLiBVc2Ugb2YgdGhpcyBlbWFpbCBvciBvZiBhbnkgaW5mb3JtYXRpb24g aW4gaXQgb3RoZXIgdGhhbiBieSB0aGUgYWRkcmVzc2VlIGlzIHVuYXV0aG9yaXNlZCBhbmQgdW5s YXdmdWwuIFdoaWxzdCByZWFzb25hYmxlIGVmZm9ydHMgYXJlIG1hZGUgdG8gZW5zdXJlIHRoYXQg YW55IGF0dGFjaG1lbnRzIGFyZSB2aXJ1cy1mcmVlLCBpdCBpcyB0aGUgcmVjaXBpZW50J3Mgc29s ZSByZXNwb25zaWJpbGl0eSB0byBzY2FuIGFsbCBhdHRhY2htZW50cyBmb3IgdmlydXNlcy4gQWxs IGNhbGxzIGFuZCBlbWFpbHMgdG8gYW5kIGZyb20gdGhpcyBjb21wYW55IG1heSBiZSBtb25pdG9y ZWQgYW5kIHJlY29yZGVkIGZvciBsZWdpdGltYXRlIHB1cnBvc2VzIHJlbGF0aW5nIHRvIHRoaXMg Y29tcGFueSdzIGJ1c2luZXNzLiBBbnkgb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZW1haWwg KG9yIGluIGFueSBhdHRhY2htZW50cykgYXJlIHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIGRvIG5v dCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIG9waW5pb25zIG9mIE1vbmV5aHViIEZpbmFuY2lh bCBUZWNobm9sb2d5IExpbWl0ZWQgb3Igb2YgYW55IG90aGVyIGdyb3VwIGNvbXBhbnkuDQoNCg0K TW9uZXlodWIgRW50ZXJwcmlzZSBpcyBhIHRyYWRpbmcgc3R5bGUgb2YgTW9uZXlodWIgRmluYW5j aWFsIFRlY2hub2xvZ3kgTGltaXRlZCB3aGljaCBpcyBhdXRob3Jpc2VkIGFuZCByZWd1bGF0ZWQg YnkgdGhlIEZpbmFuY2lhbCBDb25kdWN0IEF1dGhvcml0eSAoIkZDQSIpLiBNb25leWh1YiBGaW5h bmNpYWwgVGVjaG5vbG9neSBpcyBlbnRlcmVkIG9uIHRoZSBGaW5hbmNpYWwgU2VydmljZXMgUmVn aXN0ZXIgKEZSTiA4MDkzNjApIGF0IGh0dHBzOi8vcmVnaXN0ZXIuZmNhLm9yZy51ay8uIE1vbmV5 aHViIEZpbmFuY2lhbCBUZWNobm9sb2d5IGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVz LCBjb21wYW55IHJlZ2lzdHJhdGlvbiBudW1iZXIgMDY5MDk3NzIuIE1vbmV5aHViIEZpbmFuY2lh bCBUZWNobm9sb2d5IExpbWl0ZWQgMjAyMCDCqSBNb25leWh1YiBFbnRlcnByaXNlLCBSZWd1cyBC dWlsZGluZywgVGVtcGxlIFF1YXksIDEgRnJpYXJ5LCBCcmlzdG9sLCBCUzEgNkVBLg0KDQpESVND TEFJTUVSOiBUaGlzIGVtYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBzdWJqZWN0 IHRvIGNvcHlyaWdodCwgYW5kIHRoZSBpbmZvcm1hdGlvbiBpbiBpdCBpcyBjb25maWRlbnRpYWwu IFVzZSBvZiB0aGlzIGVtYWlsIG9yIG9mIGFueSBpbmZvcm1hdGlvbiBpbiBpdCBvdGhlciB0aGFu IGJ5IHRoZSBhZGRyZXNzZWUgaXMgdW5hdXRob3Jpc2VkIGFuZCB1bmxhd2Z1bC4gV2hpbHN0IHJl YXNvbmFibGUgZWZmb3J0cyBhcmUgbWFkZSB0byBlbnN1cmUgdGhhdCBhbnkgYXR0YWNobWVudHMg YXJlIHZpcnVzLWZyZWUsIGl0IGlzIHRoZSByZWNpcGllbnQncyBzb2xlIHJlc3BvbnNpYmlsaXR5 IHRvIHNjYW4gYWxsIGF0dGFjaG1lbnRzIGZvciB2aXJ1c2VzLiBBbGwgY2FsbHMgYW5kIGVtYWls cyB0byBhbmQgZnJvbSB0aGlzIGNvbXBhbnkgbWF5IGJlIG1vbml0b3JlZCBhbmQgcmVjb3JkZWQg Zm9yIGxlZ2l0aW1hdGUgcHVycG9zZXMgcmVsYXRpbmcgdG8gdGhpcyBjb21wYW55J3MgYnVzaW5l c3MuIEFueSBvcGluaW9ucyBleHByZXNzZWQgaW4gdGhpcyBlbWFpbCAob3IgaW4gYW55IGF0dGFj aG1lbnRzKSBhcmUgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJl cHJlc2VudCB0aGUgb3BpbmlvbnMgb2YgTW9uZXlodWIgRmluYW5jaWFsIFRlY2hub2xvZ3kgTGlt aXRlZCBvciBvZiBhbnkgb3RoZXIgZ3JvdXAgY29tcGFueS4NCg0K From nobody Wed Dec 16 01:09:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8033A040B for ; Wed, 16 Dec 2020 01:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4jIEvzubO6z for ; Wed, 16 Dec 2020 01:09:31 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 DF1CA3A046A for ; Wed, 16 Dec 2020 01:09:30 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id j16so1579469edr.0 for ; Wed, 16 Dec 2020 01:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5MHmKvcC6To3n1rj7IJNmHxwsIZKULl8QkMXBJh4hKE=; b=JgqPtTnLO+3VgqL4NKLE4m9Go/BBvcGq1vbJ4C99rLh+B0rNBT5GU77nt3Be+RmlLG AG9SWQT4+0F/1klv6CZQwdQItNoLqb6kSVVs5UJykbpNcBT0D9bgfp429QoxtBBX/bAH esE4nQRzY7TODqsQdv9Pq0HSiVXNc3F838vIk= 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=5MHmKvcC6To3n1rj7IJNmHxwsIZKULl8QkMXBJh4hKE=; b=Znq2Y3qKJrn62BtnoFIi+XduNvK81mJ+C+R8oY3dv+vi4a4q8JsfiMr72yxOnSpYkF 0Vkbjxb14Fl1QgZz2Ss/EDsKaF2D3QXfMn7LdYivUtlvLwB799eeA4HEhVxGp0jzF7Va vgAwwRXdhp6aFvAw88xuGq2YEvb7YwHNaQISxaw/5aF84OAFRrYcQu42gNNL7y4LdQa0 IKhKYW1j2n6JNUH5SRnPpiW2EV9YcitAJ7n7LRhCmyizK4tFARGNyFARsOZu5IBsc1qW w0a9VcNps0ran/sBWTLAgNFeyIwE1PmbTLPSEowKGBs0dRHNy/gOARiFdxwest5u21IS w6rw== X-Gm-Message-State: AOAM530P0x8rUHDbDhYjg6aZOiCV8838wgCedeIJtfmHW9g+Z7He3hTB VPgd9tMRaLQyNOx8PGdHqAI1hzxP3+d3j+QIeckxpk+syRuk0jXEZeuG88M3h1MYZAsUZ7Kfco2 mx3d6fwnBFbYsWsk= X-Google-Smtp-Source: ABdhPJzC78xbmiQa4ifHh/0p9WNtQMZeGqj3HMo6BvZz1ufVf+T/G9m2q+3mK2oe+0rI7gXP6mS9jkapu2tS6zAAXX8= X-Received: by 2002:a05:6402:8d9:: with SMTP id d25mr16183979edz.278.1608109768751; Wed, 16 Dec 2020 01:09:28 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> In-Reply-To: From: Dave Tonge Date: Wed, 16 Dec 2020 10:09:17 +0100 Message-ID: To: Dick Hardt Cc: Fabien Imbault , Justin Richer , Steve Moore , Torsten Lodderstedt , txauth gnap Content-Type: multipart/alternative; boundary="00000000000086e60f05b6913b8f" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 16 Dec 2020 09:09:39 -0000 --00000000000086e60f05b6913b8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Dave: which points changed your mind? 1. The issue with re-using client authentication across endpoints in the OAuth 2 world (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods_supported, introspection_endpoint_auth_methods_supported...) 2. The clear articulation of the 3 different functions of the AS (including the idea of a self-hosted AS) 3. The aim to support a more dynamic environment where client authentication only happens in the first interaction between the RC and the AS 4. The agreement that there should be further discussion on whether this access token should be rotated, and whether it should be an identifier of the grant. On Wed, 16 Dec 2020 at 00:02, Dick Hardt wrote: > Dave: which points changed your mind? > > On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge > wrote: > >> Thanks for the detailed response. >> >> I think you make the points well and I'm now in favour of the PR. >> However I do think that to keep the consistency that keeps being >> discussed, that the tokens shouldn't be rotated. >> >> I also think it would be good to have a discussion about "grant >> management" and identifiers for a grant. >> >> Dave >> >> On Tue, 15 Dec 2020 at 17:30, Justin Richer wrote: >> >>> On Dec 15, 2020, at 10:50 AM, Dave Tonge >>> wrote: >>> >>> >>> > The access token pattern has a lot of benefits, otherwise we wouldn= =E2=80=99t >>> have an entire OAuth ecosystem based on it >>> >>> *But what are the benefits in this particular use case?* The >>> continuation API is not like any other API - it is integral to the AS. >>> There are quite a few extensions to OAuth that use client authenticatio= n >>> rather than access tokens. >>> >>> >>> Yes, and the propagation of that has lead to a mess in the OAuth world. >>> You=E2=80=99ve got re-definitions of client authentications at all diff= erent >>> endpoints, they=E2=80=99re technically allowed to vary between endpoint= s (though I >>> don=E2=80=99t know of it happening in practice, that feels like a downg= rade attack >>> waiting to happen to someone). Then there=E2=80=99s the fact that all t= he newest >>> security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 do= n=E2=80=99t rely on client >>> authentication at all to achieve security. All of these work without th= e >>> client having credentials previously known to the AS, and we already kn= ow >>> that GNAP is going to need to live in this more dynamic world. We need = to >>> think beyond what OAuth 2 has done in the past, and especially from our >>> perceptions and assumptions of the models that drive OAuth 2=E2=80=99s = decisions, >>> lest we repeat its mistakes. >>> >>> Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2= =80=9D as a point. >>> In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the server side, = but in OAuth 2 we >>> split that into the RS concept. Even though in practice, a lot of RS=E2= =80=99s are >>> still integrated to the AS in some fashion because it=E2=80=99s a singl= e service, >>> OAuth 2 is clear about what=E2=80=99s expected to be known by each comp= onent. For >>> the AS as currently defined in GNAP, I=E2=80=99m seeing three distinct = functions. >>> As per the Terminology discussion, we don=E2=80=99t have explicit names= for these >>> yet: >>> >>> - starting a request; this is an endpoint to kick things off; it needs >>> to be able to look up the rights asked for by the client (if it knows t= he >>> client at all ahead of time) and make initial decisions about needed >>> interaction and follow up >>> - continuing a request; this is an API that needs to know the context >>> of the request itself, including which key it=E2=80=99s bound to; this = is separate >>> from any identity of the client and possibly the user, but an AS >>> implementation that has access to those elements can use them >>> - interacting with the user; this is front-facing and in OAuth today i= s >>> already deployed as a separate service in some places, we should embrac= e >>> that at the very least (but doing so formally is a separate issue) >>> >>> Why separate these in this way? There is immense power in having a >>> single consistent way to start the process. The =E2=80=9Ccontinuation A= PI=E2=80=9D gives us >>> an HTTP-defined mechanism for managing a request over time, including t= he >>> simple case of returning information from the front channel, but people >>> have already raised the question of non-HTTP and self-hosted AS=E2=80= =99s, which >>> would probably want a different kind of continuation API to communicate= to >>> the AS. The same thing with separating out the interaction: there are g= oing >>> to be a lot of different ways to handle interaction out there, and not = all >>> of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way that a = simple >>> implementation might do. We=E2=80=99re defining a protocol based strong= ly on HTTP >>> and JSON, but we should structure it in such a way that it can be exten= ded >>> and translated elsewhere in a clear way. >>> >>> This all raises the question: if we can rely on a unique URL for >>> redirect-based interaction, why not here? The simple reason is that a U= RL >>> is the :only: mechanism we have in the front channel for passing >>> information, and we need to warn implementors against including sensiti= ve >>> information in it, and we need to protect it with additional items. We = have >>> access to more than just URLs when we=E2=80=99re dealing with the conti= nuation API, >>> and we ought to make use of all of our tools in ways that are consisten= t >>> and make sense. >>> >>> From a previous email the advantages I see are: >>> - more data can be encoded in a token than in a uri (this seems more o= f >>> an edge case) >>> - it can be an identifier for the grant (I don't agree with this) >>> >>> >>> It allows the parts above to live separately, even if they don=E2=80=99= t HAVE >>> to. And it simplifies what we=E2=80=99re asking the client to do by mak= ing it >>> consistent with other parts of the ecosystem. The AS offering an API >>> doesn=E2=80=99t :have: to be different, and OpenID Connect showed us, w= ith the >>> UserInfo Endpoint, that that=E2=80=99s very much the case in practice. >>> >>> Having my client code do very similar things in slightly different ways >>> is not simpler. >>> >>> >>> Another question I have: *do we envisage granting access tokens to the >>> RC that will allow it to manage multiple grants*? >>> >>> >>> I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t b= een brought up as >>> a use case to date. >>> >>> >>> I also think there will be confusion with the signing being used for >>> different things. Maybe it just needs to be called out in the spec that= : >>> >>> Request 1: signature =3D client authentication >>> Request 2+: signature =3D proof of possession for access token >>> >>> >>> That=E2=80=99s more or less the intent of what=E2=80=99s in the specifi= cation right now, >>> and why all the signature methods, which are used for both client auth = and >>> token possession, are all together in section 8 and not separated by us= e. >>> (With the caveat: it=E2=80=99s only client authentication in the first= request if >>> the AS knows about the client instance ahead of time, which isn=E2=80= =99t always >>> going to be true.) That all can likely be made clearer, as is always th= e >>> case with spec text. But you can use the signature methods with and wit= hout >>> access tokens, and it only gets used without in an initial call where y= ou >>> don=E2=80=99t :have: an access token to present. >>> >>> Separating the different kinds of =E2=80=9Cclient authentication" out i= n OAuth >>> is the source of some real confusion. Like right now, what happens if y= ou >>> try to combine a client assertion, signed request objects for PAR, and = DPoP >>> proofs, all in a single request? All of these are optional and all of t= hem >>> =E2=80=9Cdo client authentication=E2=80=9D in some arguable fashion. I= =E2=80=99ve worked on several >>> systems and implemented these things, and their interplay is really >>> confusing to manage and can go sideways really fast. And that=E2=80=99s= just the >>> work for a single endpoint, this gets repeated for introspection, >>> revocation, CIBA, device, and on. >>> >>> At the end of the day I=E2=80=99m in favor of giving the client develop= ers a >>> very clear set of directions on what they need to do and how they need = to >>> access things, and treating the continuation as a token-bound API is, t= o >>> me, the clearest pattern we can offer for this piece. >>> >>> =E2=80=94 Justin >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, 15 Dec 2020 at 15:33, Justin Richer wrote: >>> >>>> I agree with Fabien that the persistent identifier is a separate issue= . >>>> The current spec re-uses the access token for this artifact, but that= =E2=80=99s >>>> potentially brittle and could be changed out for something else. There= =E2=80=99s an >>>> issue asking for expanding on the use cases for this functionality (wh= ich >>>> hasn=E2=80=99t been addressed by this PR): >>>> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>> >>>> A potentially-rotating URI would be just as brittle, and so having a >>>> single codified identifier for this artifact would be useful, but it d= oes >>>> assume some things about the nature of the AS. Every other use the cli= ent >>>> has to manage the ongoing request over time doesn=E2=80=99t need an ex= plicit >>>> identifier. Just like with OAuth-protected APIs, the server can determ= ine >>>> the context not just from the URI but from the rest of the request, >>>> including the access token itself. This is both more common and more >>>> powerful than a strict reading of REST designs. It also follows the HA= TEOS >>>> principles as the entire HTTP request is taken into account, including= the >>>> access token and signature portions. >>>> >>>> I=E2=80=99ll also point out that the rotation of these credentials is = also >>>> filed as a separate issue that=E2=80=99s not being addressed right now= , so we can >>>> revisit that discussion separately: >>>> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>> >>>> As for the name, we could give it a different label. We have this same >>>> pattern of issuing a resource-specific access token alongside a URL in= the >>>> Dynamic Registration specification, both in OAuth ( >>>> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( >>>> https://openid.net/specs/openid-connect-registration-1_0.html#Registra= tionResponse). >>>> Here it=E2=80=99s called the =E2=80=9Cregistration access token=E2=80= =9D =E2=80=94 but what=E2=80=99s important >>>> there, as it is here, is that it=E2=80=99s not a different kind of art= ifact that >>>> the client now has to figure out how to use, it=E2=80=99s an access to= ken plain and >>>> simple. In the OAuth world this is a bearer token, since that=E2=80=99= s what OAuth >>>> 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2= =80=99s what we=E2=80=99re >>>> looking to build on. This is also related to another future discussion >>>> about responses tying an access token to a specific API that=E2=80=99s= told to the >>>> client, as we could potentially re-use those components and concepts h= ere >>>> as well: >>>> >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 >>>> >>>> And finally, no speculation on the complexity is needed: I implemented >>>> this pattern several months ago during the design team discussions whe= n we >>>> were considering this pattern, and the code is all online for people t= o >>>> see. >>>> >>>> https://github.com/bspk/oauth.xyz-java/ >>>> >>>> On the AS side, the most interesting code to this discussion is in the >>>> TransactionEndpoint class: >>>> >>>> >>>> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io= /bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java >>>> >>>> Here, you=E2=80=99ll see that on initial request, the server looks up = the >>>> client to see if it=E2=80=99s been registered, but after that, it make= s sure that >>>> the token and key are appropriate for the ongoing request. From the cl= ient >>>> side it=E2=80=99s even simpler. The client=E2=80=99s got a small servi= ce function to manage >>>> the different signature methods that are implemented, and all of them = can >>>> take in an optional access token: >>>> >>>> >>>> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io= /bspk/oauth/xyz/http/SigningRestTemplateService.java >>>> >>>> The heavy lift is doing the actual signing, and you need that in order >>>> to start the process anyway. Managing the access token as an artifact = to >>>> use at the API is completely trivial since the client already needs to >>>> manage its own state internally to do any of this. And note that all o= f >>>> this is changed from how it was before: Previously, the XYZ Protocol h= ad >>>> used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that th= e client would use to >>>> continue the request. However, this simple model was limiting, and the >>>> design team adopted XAuth=E2=80=99s model of continuation being an API= . In doing >>>> so, we made it like all of the other APIs the client is going to call:= in >>>> the initial state, it doesn=E2=80=99t have any kind of access rights, = it=E2=80=99s just >>>> calling. From that initial call forward, the AS just needs to know tha= t the >>>> token and key match what it expects. >>>> >>>> In summary, my views are: >>>> - The access token pattern has a lot of benefits, otherwise we >>>> wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>>> - Magic URIs have a lot of drawbacks which are well understood; while >>>> they can be mitigated, they can also be avoided >>>> - Continuation is an API, and treating it like the other kinds of API >>>> the client would call makes sense >>>> - Calling this by a special name, like =E2=80=9Cgrant access token=E2= =80=9D or >>>> =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should fun= ction like any other >>>> access token >>>> - The heavy lift for clients is on protecting the message >>>> cryptographically, which they need to do anyway >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> On Dec 15, 2020, at 7:50 AM, Dave Tonge >>>> wrote: >>>> >>>> The persistent identifier is not a different issue, the current access >>>> token is used to reference an existing grant >>>> >>>> >>>> >>>> It may not be more difficult for a client to *use* an access token at >>>> the AS / RS. But there is definitely an overhead on the client to >>>> *manage* this separate access token. >>>> >>>> >>>> >>>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault >>>> wrote: >>>> >>>>> I think we always said the access token was different, and handled as >>>>> a bound token. >>>>> >>>>> But it doesn't mean it's more difficult for the client that already >>>>> needs to be able to handle tokens anyway (bearer or not, both cases c= ould >>>>> occur). It's mostly consolidating the logic. >>>>> >>>>> You're anticipating a lot of issues which have no specific reason to >>>>> occur, such as "can't be used with the token management APIs?". The >>>>> management API is part of the same general flow. >>>>> Anticipating issues with rotation is useful, but there are also many >>>>> ways it can be hard to manage through a stateful approach too. And >>>>> fundamentally, having everything in a common model (both for the inte= rnals >>>>> of the AS and for the API calls) will help improve by a large margin = what >>>>> is probably the weakest point in today's infrastructure. But it's ear= ly to >>>>> be definitive as to the downstream impact either way. >>>>> >>>>> As for a persistent identifier instead of a continuation API, and >>>>> generally the end of your message, it's a totally unrelated issue to = this >>>>> PR, so I suggest we don't discuss that here, but in a separate issue = if >>>>> needed. >>>>> >>>>> Fabien >>>>> >>>>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>>>> wrote: >>>>> >>>>>> So we've established that this is a different access token, that >>>>>> requires different handling at the client. So keeping it could cause= more >>>>>> confusion? >>>>>> >>>>>> As an RC, I will have to store the continue `uri` as although it >>>>>> could be static it could also be dynamic. Why do I need to store an = access >>>>>> token as well. It brings me no benefit as an RC, in fact it brings m= ore >>>>>> complexity. As I will now need to manage multiple types of tokens wi= th >>>>>> different lifecycles: >>>>>> >>>>>> *Continuation token* >>>>>> - can only be used at the continue endpoint (the name of which is >>>>>> confusing as I can use this endpoint to revoke a grant or get metada= ta on >>>>>> the grant). >>>>>> - may be rotated each time it is used, or may not be >>>>>> - provided in the `continue` section of the response >>>>>> - must be sender-constrained >>>>>> - can't be used with the token management APIs? >>>>>> - can be used to identify the grant when making subsequent grants >>>>>> >>>>>> *Access token(s) to use at RS* >>>>>> - can only be used at the specified RS >>>>>> - may be sender constrained >>>>>> - when used at the RS, will not result in rotation >>>>>> >>>>>> From my perspective, most use-cases will require the RC to have a >>>>>> persistent identifier for the grant. Why not bring this into the pro= tocol >>>>>> and let the AS provide this persistent identifier (through the form = of the >>>>>> continue uri). Using a rotating access token as a persistent identif= ier >>>>>> doesn't seem like the right choice. >>>>>> >>>>>> I see no security benefit to having the continuation access token. I= t >>>>>> doesn't matter if the continue uri leaks as it is useless without an >>>>>> accompanying signature, i.e. any security benefit of having an acces= s token >>>>>> is already provided by having a signature. >>>>>> >>>>>> The only benefits that I can see are: >>>>>> - If the AS wants to be fully stateless, then you can encode more >>>>>> data in a token than in a uri >>>>>> - If the AS wants to have a static endpoint for CRUD operations on >>>>>> the grant >>>>>> - To allow the AS to identity a previous grant >>>>>> >>>>>> If we dropped the access token for the continue endpoint and rather >>>>>> mandated a dynamic uri this would make things conceptually easier to >>>>>> understand, easier for the RC to implement, easier to debug and less= chance >>>>>> of errors when rotating tokens (i.e. race conditions could be quite = likely >>>>>> if the AS always rotates the token) >>>>>> >>>>>> *One-off grant with no continuation or ongoing management:* >>>>>> RC sends signature and metadata, no `continue` response provided, >>>>>> therefore no grant management possible >>>>>> >>>>>> *Grant with ongoing management* >>>>>> RC sends signature and metadata, AS responds with a continue uri tha= t >>>>>> has these purposes: >>>>>> - can be used by the RC to continue/update, read or revoke the gran= t >>>>>> - can be used by the RC when making a new grant to identify the >>>>>> previous grant >>>>>> >>>>>> As an RC the only permanent items I need to store are: >>>>>> - the continue uri associated with the grant >>>>>> - any access tokens I receive for the grant >>>>>> >>>>>> Dave >>>>>> >>>>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> Hi Torsten, >>>>>>> >>>>>>> You're right on both accounts. >>>>>>> - for the first remark, it fits quite nicely the init request / >>>>>>> continuation pattern >>>>>>> - for the second remark, it is a sort of handle for the >>>>>>> continuation request, which will eventually lead to the issuance or= refresh >>>>>>> of standard access tokens >>>>>>> >>>>>>> Having a specific name is a possibility, I actually suggested that >>>>>>> too at some point. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>>>> torsten@lodderstedt.net> wrote: >>>>>>> >>>>>>>> Hi Fabien, >>>>>>>> >>>>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com>: >>>>>>>> > >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> > On the contrary your feedback is most welcome. >>>>>>>> > >>>>>>>> > It doesn't accept any token, it needs the particular token as >>>>>>>> described in 3.1 and which is not a bearer token (that's what the = "key" : >>>>>>>> true parameter is supposed to convey). >>>>>>>> > >>>>>>>> > Let us know if you need more clarifications. >>>>>>>> >>>>>>>> Thanks for the clarification. I think only accepting this kind of >>>>>>>> token at the continuation is a good idea otherwise the AS would ne= ed to be >>>>>>>> able to parse and understand all sorts of access tokens. >>>>>>>> >>>>>>>> Conceptually, I like the idea to treat the continuation as another >>>>>>>> kind of resource. However, here are some observations I want to sh= are with >>>>>>>> you: >>>>>>>> - This resource is different as it will issue other access tokens >>>>>>>> (of this kind) to be used in subsequent continuation requests. Thi= s >>>>>>>> requires different handing on the client side. >>>>>>>> - This access token (if I understand correctly) is (or at least >>>>>>>> feels like) a handle for the underlying grant. So it is kind of th= e super >>>>>>>> access token to obtain other access tokens. >>>>>>>> >>>>>>>> I would consider using a different term to refer to this special >>>>>>>> access token, grant token or grant handle for example, in order to= prevent >>>>>>>> confusion. >>>>>>>> >>>>>>>> best regards, >>>>>>>> Torsten. >>>>>>>> >>>>>>>> >>>>>>>> > >>>>>>>> > Best >>>>>>>> > Fabien >>>>>>>> > >>>>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>>>> > Hi all, >>>>>>>> > >>>>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me quest= ion seems >>>>>>>> naive. >>>>>>>> > >>>>>>>> > After having skimmed through the current draft and the PR, I=E2= =80=98m >>>>>>>> not sure whether the continuation requests accepts any access toke= n issued >>>>>>>> to the RC or the particular access token returned in the =E2=80=9E= continue=E2=80=9C element >>>>>>>> in section 3.1.. >>>>>>>> > >>>>>>>> > Can you please shed some light on this? >>>>>>>> > >>>>>>>> > kind regards, >>>>>>>> > Torsten. >>>>>>>> > >>>>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com>: >>>>>>>> >> >>>>>>>> >> =EF=BB=BF >>>>>>>> >> You're completely right. Allowing the dev to be lazy is a very >>>>>>>> good thing in general, because it's what we know will work :-) >>>>>>>> >> >>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore >>>>>>>> a =C3=A9crit : >>>>>>>> >> Hi Fabien, >>>>>>>> >> >>>>>>>> >> For #3) Even after I typed out the hypothetical attack, that wa= s >>>>>>>> sort of in the back of my mind, it isn't a huge risk there. So I a= ctually >>>>>>>> agree with Dick there. Something doesn't sit right with me for the= unique >>>>>>>> URL solution, so I don't like it and came up with a hypothetical t= hat seems >>>>>>>> like it could be a down side. >>>>>>>> >> >>>>>>>> >> I still think the access token model with the signed request is >>>>>>>> the way I'd like to go, because again, it's a mechanism I'd be imp= lementing >>>>>>>> anyway to talk to any 'normal' resource. The fact is there is _som= ething_ >>>>>>>> representing context that has to pass back and forth here, whether= that is >>>>>>>> an access token (which I feel like is more flexible for extensions= etc), a >>>>>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy deve= loper ;) >>>>>>>> >> -steve >>>>>>>> >> >>>>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >> Again speaking in my own name here. >>>>>>>> >> >>>>>>>> >> Dick, we know you'd prefer to have a different design, but this >>>>>>>> PR shouldn't be about that. >>>>>>>> >> >>>>>>>> >> Back on your 3 items : >>>>>>>> >> >>>>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>>>> decided that wouldn't be how that would work. We have a client ins= tance >>>>>>>> that allows a more generic and flexible pattern (which BTW also al= lows what >>>>>>>> you want) >>>>>>>> >> >>>>>>>> >> 2) instead of blame arguments of who's less >>>>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversati= ons, I >>>>>>>> suggest we speak in less abstract terms and ask ourselves what tha= t means >>>>>>>> in practice for devs. Stephen and several others (myself included)= have >>>>>>>> expressed that it wouldn't be harder to implement, it would even s= implify >>>>>>>> things quite a lot. If you disagree please send us a code sample t= o really >>>>>>>> show that point by example, because that's really not obvious. >>>>>>>> >> >>>>>>>> >> 3) "If someone has the client credentials, they can impersonate >>>>>>>> the client, and all bets are off." Are you seriously making this a= rgument? >>>>>>>> Because if you have a better proposal than using cryptographic key= s, I'm >>>>>>>> all hears. You make it look like there's a problem, while in reali= ty we're >>>>>>>> only relying on the basic assumption of all modern digital communi= cations. >>>>>>>> >> >>>>>>>> >> And more importantly you never responded to the issues of how t= o >>>>>>>> avoid the security pitfalls of what you proposed. >>>>>>>> >> >>>>>>>> >> Fabien >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt >>>>>>>> a =C3=A9crit : >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>>>>> wrote: >>>>>>>> >> But from the spec: >>>>>>>> >> " >>>>>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>>>>> identify itself by including the client field of the request... >>>>>>>> >> ... >>>>>>>> >> key (object / string) : The public key of the RC to be used in >>>>>>>> this request as described in {{request-key}}. This field is REQUIR= ED. >>>>>>>> >> ... >>>>>>>> >> " >>>>>>>> >> So on the initial request, the key will be there. >>>>>>>> >> >>>>>>>> >> The client field can be an object or a string. If the client is >>>>>>>> pre-registered, then a string could be provided instead of an obje= ct. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> If you don't have the access token, then how do you >>>>>>>> differentiate between two requests from the same web application b= y two >>>>>>>> different users? Is the web application supposed to have different >>>>>>>> credentials for every request? >>>>>>>> >> >>>>>>>> >> The AS returns a URI for manipulating the request. I would >>>>>>>> change the spec so that each request would have a unique URI. This= is the >>>>>>>> usually RESTful pattern that the resource (the grant request) has = an URI. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> So in this case, the easy way out is to pass the access token t= o >>>>>>>> the client, who then, as i stated before, treats the continue requ= est as a >>>>>>>> RS call (albeit a specialized version of the RS where the RS is th= e AS) OR >>>>>>>> to use the unique URL, >>>>>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>>>>> (What would be the point of that attack, I don't know, I guess if = someone >>>>>>>> had the client credentials but not any subjects/resources they cou= ld try to >>>>>>>> intercept the grant via continue... I just don't feel right lockin= g things >>>>>>>> down to unique URLs that way.) >>>>>>>> >> >>>>>>>> >> If someone has the client credentials, they can impersonate the >>>>>>>> client, and all bets are off. >>>>>>>> >> >>>>>>>> >> LOTS of RS servers return a resource specific URL -- my proposa= l >>>>>>>> is no different. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> -steve >>>>>>>> >> >>>>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>>>>> wrote: >>>>>>>> >> Hi Stephen >>>>>>>> >> >>>>>>>> >> The client is signing the first request. The key *might* be in >>>>>>>> the body. The client is signing all the subsequent requests as wel= l. The >>>>>>>> "access token" is not needed by the client to prove it is authoriz= ed as the >>>>>>>> client is proving it is the same client again. >>>>>>>> >> >>>>>>>> >> In other words, I don't see the need for an access token, so it >>>>>>>> does not need to be put in a URL or an auth header. >>>>>>>> >> >>>>>>>> >> If a developer really, really wants to hand context back to the >>>>>>>> client for subsequent calls, they can put it in the URL or some ot= her >>>>>>>> method. Putting it in the HTTP Authorization header is confusing b= ecause it >>>>>>>> is NOT an access token -- it is the context of the request. >>>>>>>> >> >>>>>>>> >> =E1=90=A7 >>>>>>>> >> >>>>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>>>>> wrote: >>>>>>>> >> Even though I've only been lightly following things, I feel the >>>>>>>> need to voice my preference as a developer since I will probably s= omeday >>>>>>>> have to either write a RC or RS... >>>>>>>> >> >>>>>>>> >> The way I see it is the RC makes the initial request to the AS >>>>>>>> as part of this request, it provides it's key in the body... (So n= o use of >>>>>>>> the Authorization header) >>>>>>>> >> At this point that request, represented by the continue URL + >>>>>>>> "Access Token", from my lazy developer standpoint, is a Resource E= ndpoint >>>>>>>> and Access Token, and the AS is acting as a specialized RS in this= case. >>>>>>>> >> So my client posts to whatever URL with the 'access token' in >>>>>>>> the authorization header, just like acting on any other resource I= have a >>>>>>>> token for. YES, I get a new token value to use every call, and the= re is a >>>>>>>> decision point of "Do I have another continue, or do I have a real= token >>>>>>>> for the resource..." But the mechanism is the same to me in the cl= ient. >>>>>>>> >> Personally I like that, because if I have an access_token, I >>>>>>>> already think "Put it in the auth header." >>>>>>>> >> >>>>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>>>> >> -steve >>>>>>>> >> >>>>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>>>> wrote: >>>>>>>> >> inline ... >>>>>>>> >> >>>>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>>> wrote: >>>>>>>> >> Others had already responded to this previous thread, but I >>>>>>>> wanted to add a couple points to clarify some things. >>>>>>>> >> >>>>>>>> >>> 3) What the client has to do with the "access token" is not th= e >>>>>>>> same as access tokens for an RS. The client gets a new "access tok= en" for >>>>>>>> each grant request, and for each API call to the AS, and the clien= t learns >>>>>>>> it can not make any more API calls for that specific request when = it does >>>>>>>> not get an "access token" back. This is a completely different des= ign >>>>>>>> pattern than calling an RS API with an access token, and is a new = design >>>>>>>> pattern for calling APIs. This adds complexity to the client that = it would >>>>>>>> not normally have, and I don't think GNAP is the right place to st= art a new >>>>>>>> design pattern. >>>>>>>> >>> >>>>>>>> >> >>>>>>>> >> I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole >>>>>>>> point of the design is that the client would be doing the same thi= ng with >>>>>>>> the access token at the AS that it does with the RS by re-using th= e access >>>>>>>> token structure. Can you please describe what the differences are,= apart >>>>>>>> from the rotation? Presentation of the token and signing of the me= ssage are >>>>>>>> identical. >>>>>>>> >> >>>>>>>> >> The client is getting the "access token" from its API. It is no= t >>>>>>>> using an "access_token" in other API calls to the AS. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>>>> continuation responses is a separate issue to be discussed: >>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>>> >> >>>>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right p= lace to >>>>>>>> have new designs =E2=80=94 not that this is one. >>>>>>>> >> >>>>>>>> >> You are proposing a new way for an API to provide context for >>>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> 4) Clients that only want claims from the AS and no access >>>>>>>> tokens will be required to support an API calling mechanism they w= ould not >>>>>>>> have to support otherwise. >>>>>>>> >> >>>>>>>> >> Correct, but the delta between the calls a client would make >>>>>>>> with and without an access token is vanishingly small. The client = has to >>>>>>>> sign the initial request in some fashion, and it will sign the con= tinuation >>>>>>>> request in the same exact fashion, but now include an access token= in that >>>>>>>> request. >>>>>>>> >> >>>>>>>> >> Per my other point, there is no value to me in my >>>>>>>> implementations of passing context back and forth between the clie= nt and AS >>>>>>>> -- so it is extra work providing no value. >>>>>>>> >> >>>>>>>> >> Also, any client authentication mechanism that wants to use the >>>>>>>> HTTP Authentication header is precluded from using it. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> Clients making a request to an AS and not getting an access >>>>>>>> token is a new design pattern. I think it has value and should be = included, >>>>>>>> but OAuth today shows us the immense value of getting access token= s for >>>>>>>> calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern. >>>>>>>> >> >>>>>>>> >>> >>>>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>>>> mechanism for a client to delete the request, as the client is not= allowed >>>>>>>> to make a call without an "access token". >>>>>>>> >> >>>>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue= =E2=80=9D field >>>>>>>> then the client can=E2=80=99t delete the request =E2=80=94 and yes= , that=E2=80=99s intentional. The >>>>>>>> AS is telling this client instance that it can=E2=80=99t do anythi= ng else with this >>>>>>>> ongoing request. If the AS wants to allow the client to manage it,= it will >>>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D = field. >>>>>>>> >> >>>>>>>> >> There is nuance in that intention. A related concern is that >>>>>>>> deleting a request does not seem like it is a "continue" operation= . >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> >>>>>>>> >>> 6) There is no standard identifier for the request. Debugging >>>>>>>> and auditing are hampered by the client and AS having no standard = way to >>>>>>>> identifying a request. While one AS may provide a unique URL for e= ach grant >>>>>>>> request, another AS may use a persistent "access token" to identif= y the >>>>>>>> grant request, and other ASs may issue a new "access token" on eac= h API >>>>>>>> call, providing no persistent identifier for the request. >>>>>>>> >> >>>>>>>> >> Debugging and auditing this kind of thing are functions of the >>>>>>>> AS. How is interoperability harmed by different ASs having differe= nt >>>>>>>> methods to identify their internal data elements? The client doesn= =E2=80=99t need >>>>>>>> any knowledge of the AS=E2=80=99s identifiers, it just needs to kn= ow the next steps >>>>>>>> for continuing the negotiation. >>>>>>>> >> >>>>>>>> >> Debugging between the client and the AS was what I was referrin= g >>>>>>>> to. How does a client developer identify the request when communic= ating to >>>>>>>> the AS developer. Seems complicated. >>>>>>>> >> >>>>>>>> >> =E1=90=A7 >>>>>>>> >> -- >>>>>>>> >> TXAuth mailing list >>>>>>>> >> TXAuth@ietf.org >>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >> =E1=90=A7 >>>>>>>> >> -- >>>>>>>> >> TXAuth mailing list >>>>>>>> >> TXAuth@ietf.org >>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >> -- >>>>>>>> >> TXAuth mailing list >>>>>>>> >> TXAuth@ietf.org >>>>>>>> >> >>>>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listin= fo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVO= u0IQPJJYtSpI >>>>>>>> >>>>>>>> -- >>>>>>> TXAuth mailing list >>>>>>> TXAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dave Tonge >>>>>> CTO >>>>>> [image: Moneyhub Enterprise] >>>>>> >>>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>>> BS1 6FL >>>>>> >>>>>> t: +44 (0)117 280 5120 >>>>>> >>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at *https://register.fca.or= g.uk/ >>>>>> *. Moneyhub Financial Technology is >>>>>> registered in England & Wales, company registration number 06909772 >>>>>> . >>>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at >>>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>>> registered in England & Wales, company registration number 06909772. >>>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterpris= e, Regus >>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>>> >>>>>> . >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> >>>> >>>> -- >>>> Dave Tonge >>>> CTO >>>> [image: Moneyhub Enterprise] >>>> >>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>>> 6FL >>>> >>>> t: +44 (0)117 280 5120 >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at *https://register.fca.org.= uk/ >>>> *. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772 . >>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>> >>>> . >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >>> -- >>> Dave Tonge >>> CTO >>> [image: Moneyhub Enterprise] >>> >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>> 6FL >>> >>> t: +44 (0)117 280 5120 >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at *https://register.fca.org.u= k/ >>> *. Moneyhub Financial Technology is >>> registered in England & Wales, company registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, >>> BS1 6EA >>> >>> . >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> >>> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >> 6FL >> >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA >> >> . >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --00000000000086e60f05b6913b8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    >=C2=A0Dave: which points changed your mind?

    1. The issue with re-using client authentication across endpoints= in the OAuth 2 world (token_endpoint_auth_methods_supported,=C2=A0revocati= on_endpoint_auth_methods_supported,=C2=A0introspection_endpoint_auth_method= s_supported...)


    <= /div>
    3. The aim to support a more dynamic environment wher= e client authentication only happens in the first interaction between the R= C and the AS

    4. The agreement that = there should be further discussion on whether this access token should be r= otated, and whether it should be an identifier of the grant.


    On Wed, 16 Dec 2020 at 00:02, Dick Hardt <dick.hardt@gmail.com> wrote:
    Dave: which points chang= ed your mind?

    On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <dave.tonge@moneyhub.com<= /a>> wrote:
    <= div dir=3D"ltr">
    Thanks for the detailed response.

    I think you make the points well and I'm now = in favour of the PR.
    However I do think that to keep the c= onsistency that keeps being discussed, that the tokens shouldn't be rot= ated.=C2=A0

    I also think it would = be good to have a discussion about "grant management" and identif= iers for a grant.

    On Tue, 15 Dec 2020 at 17:30, Justin Richer <jricher@mit.edu> wrote:
    On Dec 15, 20= 20, at 10:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    >=C2=A0The access token pattern has a = lot of benefits, otherwise we wouldn=E2=80=99t have an entire OAuth ecosyst= em based on it

    But wha= t are the benefits=C2=A0in this particular use case? The continuation A= PI is not like any other API - it is integral to the AS. There are quite a = few extensions to OAuth that use client authentication rather than access t= okens.

    Yes, and the propa= gation of that has lead to a mess in the OAuth world. You=E2=80=99ve got re= -definitions of client authentications at all different endpoints, they=E2= =80=99re technically allowed to vary between endpoints (though I don=E2=80= =99t know of it happening in practice, that feels like a downgrade attack w= aiting to happen to someone). Then there=E2=80=99s the fact that all the ne= west security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 d= on=E2=80=99t rely on client authentication at all to achieve security. All = of these work without the client having credentials previously known to the= AS, and we already know that GNAP is going to need to live in this more dy= namic world. We need to think beyond what OAuth 2 has done in the past, and= especially from our perceptions and assumptions of the models that drive O= Auth 2=E2=80=99s decisions, lest we repeat its mistakes.=C2=A0
    Also, I want to challenge this idea of =E2=80=9Cintegral to th= e AS=E2=80=9D as a point. In OAuth 1, the API was =E2=80=9Cintegral=E2=80= =9D to the server side, but in OAuth 2 we split that into the RS concept. E= ven though in practice, a lot of RS=E2=80=99s are still integrated to the A= S in some fashion because it=E2=80=99s a single service, OAuth 2 is clear a= bout what=E2=80=99s expected to be known by each component. For the AS as c= urrently defined in GNAP, I=E2=80=99m seeing three distinct functions. As p= er the Terminology discussion, we don=E2=80=99t have explicit names for the= se yet:

    =C2=A0- starting a request; this is an end= point to kick things off; it needs to be able to look up the rights asked f= or by the client (if it knows the client at all ahead of time) and make ini= tial decisions about needed interaction and follow up
    =C2=A0- continui= ng a request; this is an API that needs to know the context of the request = itself, including which key it=E2=80=99s bound to; this is separate from an= y identity of the client and possibly the user, but an AS implementation th= at has access to those elements can use them
    =C2=A0- interacting = with the user; this is front-facing and in OAuth today is already deployed = as a separate service in some places, we should embrace that at the very le= ast (but doing so formally is a separate issue)

    Wh= y separate these in this way? There is immense power in having a single con= sistent way to start the process. The =E2=80=9Ccontinuation API=E2=80=9D gi= ves us an HTTP-defined mechanism for managing a request over time, includin= g the simple case of returning information from the front channel, but peop= le have already raised the question of non-HTTP and self-hosted AS=E2=80=99= s, which would probably want a different kind of continuation API to commun= icate to the AS. The same thing with separating out the interaction: there = are going to be a lot of different ways to handle interaction out there, an= d not all of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way t= hat a simple implementation might do. We=E2=80=99re defining a protocol bas= ed strongly on HTTP and JSON, but we should structure it in such a way that= it can be extended and translated elsewhere in a clear way.

    =
    Th= is all raises the question: if we can rely on a unique URL for redirect-bas= ed interaction, why not here? The simple reason is that a URL is the :only:= mechanism we have in the front channel for passing information, and we nee= d to warn implementors against including sensitive information in it, and w= e need to protect it with additional items. We have access to more than jus= t URLs when we=E2=80=99re dealing with the continuation API, and we ought t= o make use of all of our tools in ways that are consistent and make sense.<= /div>

    From a previous email the advantages I see are:<= /div>
    =C2=A0- more data can be encoded in a tok= en than in a uri (this seems more of an edge case)
    =C2=A0- it can be an identifier for the grant (I don't agree = with this)

    It allows the = parts above to live separately, even if they don=E2=80=99t HAVE to. And it = simplifies what we=E2=80=99re asking the client to do by making it consiste= nt with other parts of the ecosystem. The AS offering an API doesn=E2=80=99= t :have: to be different, and OpenID Connect showed us, with the UserInfo E= ndpoint, that that=E2=80=99s very much the case in practice.=C2=A0

    Having my client code do very similar things in slightly d= ifferent ways is not simpler.


    Another question I have: do we envisage granting access tokens to t= he RC that will allow it to manage multiple grants?=C2=A0=C2=A0

    I don=E2=80=99t see that happeni= ng, personally, and it hasn=E2=80=99t been brought up as a use case to date= .=C2=A0


    I also think ther= e will be confusion with the signing being used for different things. Maybe= it just needs to be called out in the spec that:

    Request 1: signature = =3D client authentication
    Request 2+: sig= nature =3D proof of possession for access token


    That=E2=80=99= s more or less the intent of what=E2=80=99s in the specification right now,= and why all the signature methods, which are used for both client auth and= token possession, are all together in section 8 and not separated by use. = =C2=A0(With the caveat: it=E2=80=99s only client authentication in the firs= t request if the AS knows about the client instance ahead of time, which is= n=E2=80=99t always going to be true.) That all can likely be made clearer, = as is always the case with spec text. But you can use the signature methods= with and without access tokens, and it only gets used without in an initia= l call where you don=E2=80=99t :have: an access token to present.

    Separating the different kinds of =E2=80=9Cclient authentic= ation" out in OAuth is the source of some real confusion. Like right n= ow, what happens if you try to combine a client assertion, signed request o= bjects for PAR, and DPoP proofs, all in a single request? All of these are = optional and all of them =E2=80=9Cdo client authentication=E2=80=9D in some= arguable fashion. I=E2=80=99ve worked on several systems and implemented t= hese things, and their interplay is really confusing to manage and can go s= ideways really fast. And that=E2=80=99s just the work for a single endpoint= , this gets repeated for introspection, revocation, CIBA, device, and on.

    At the end of the day I=E2=80=99m in favor of givin= g the client developers a very clear set of directions on what they need to= do and how they need to access things, and treating the continuation as a = token-bound API is, to me, the clearest pattern we can offer for this piece= .

    =C2=A0=E2=80=94 Justin




    <= div class=3D"gmail_default">




    On Tue, 15 Dec 2020 at 15= :33, Justin Richer <jricher@mit.edu> wrote:
    I agree with Fabien that the persistent identifier is = a separate issue. The current spec re-uses the access token for this artifa= ct, but that=E2=80=99s potentially brittle and could be changed out for som= ething else. There=E2=80=99s an issue asking for expanding on the use cases= for this functionality (which hasn=E2=80=99t been addressed by this PR):

    A potentially-rotating URI would= be just as brittle, and so having a single codified identifier for this ar= tifact would be useful, but it does assume some things about the nature of = the AS. Every other use the client has to manage the ongoing request over t= ime doesn=E2=80=99t need an explicit identifier. Just like with OAuth-prote= cted APIs, the server can determine the context not just from the URI but f= rom the rest of the request, including the access token itself. This is bot= h more common and more powerful than a strict reading of REST designs. It a= lso follows the HATEOS principles as the entire HTTP request is taken into = account, including the access token and signature portions.=C2=A0

    I=E2=80=99ll also point out that the rotation of these cred= entials is also filed as a separate issue that=E2=80=99s not being addresse= d right now, so we can revisit that discussion separately:

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/87

    As for the name, we could give it a diffe= rent label. We have this same pattern of issuing a resource-specific access= token alongside a URL in the Dynamic Registration specification, both in O= Auth (https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connec= t (https://openid.net/specs/openid-co= nnect-registration-1_0.html#RegistrationResponse). Here it=E2=80=99s ca= lled the =E2=80=9Cregistration access token=E2=80=9D =E2=80=94 but what=E2= =80=99s important there, as it is here, is that it=E2=80=99s not a differen= t kind of artifact that the client now has to figure out how to use, it=E2= =80=99s an access token plain and simple. In the OAuth world this is a bear= er token, since that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2= =80=99ll be a bound token, as that=E2=80=99s what we=E2=80=99re looking to = build on. This is also related to another future discussion about responses= tying an access token to a specific API that=E2=80=99s told to the client,= as we could potentially re-use those components and concepts here as well:=


    And finally, no sp= eculation on the complexity is needed: I implemented this pattern several m= onths ago during the design team discussions when we were considering this = pattern, and the code is all online for people to see.=C2=A0

    =

    = On the AS side, the most interesting code to this discussion is in the Tran= sactionEndpoint class:


    Here, = you=E2=80=99ll see that on initial request, the server looks up the client = to see if it=E2=80=99s been registered, but after that, it makes sure that = the token and key are appropriate for the ongoing request. From the client = side it=E2=80=99s even simpler. The client=E2=80=99s got a small service fu= nction to manage the different signature methods that are implemented, and = all of them can take in an optional access token:=C2=A0


    =
    The heavy lift is doing the actual signing, and you need that in= order to start the process anyway. Managing the access token as an artifac= t to use at the API is completely trivial since the client already needs to= manage its own state internally to do any of this. And note that all of th= is is changed from how it was before: Previously, the XYZ Protocol had used= a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the client = would use to continue the request. However, this simple model was limiting,= and the design team adopted XAuth=E2=80=99s model of continuation being an= API. In doing so, we made it like all of the other APIs the client is goin= g to call: in the initial state, it doesn=E2=80=99t have any kind of access= rights, it=E2=80=99s just calling. From that initial call forward, the AS = just needs to know that the token and key match what it expects.=C2=A0

    In summary, my views are:
    =C2=A0- The access= token pattern has a lot of benefits, otherwise we wouldn=E2=80=99t have an= entire OAuth ecosystem based on it
    =C2=A0- Magic URIs have a lot= of drawbacks which are well understood; while they can be mitigated, they = can also be avoided
    =C2=A0- Continuation is an API, and treating = it like the other kinds of API the client would call makes sense
    = =C2=A0- Calling this by a special name, like =E2=80=9Cgrant access token=E2= =80=9D or =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it shoul= d function like any other access token
    =C2=A0- The heavy lift for= clients is on protecting the message cryptographically, which they need to= do anyway

    =C2=A0=E2=80=94 Justin


    On Dec 15, 2020, at 7:50 AM, Dave Ton= ge <dave.to= nge@moneyhub.com> wrote:

    reference an existing grant=C2=A0
    =

    It may not be more difficult for a client= to use an= access token at the AS / RS. But there=C2=A0is definitely an overhead on t= he client to m= anage=C2=A0this separate access token.=C2=A0



    On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    I think we always said the access token was differ= ent, and handled as a bound token.

    But it doesn't me= an it's more difficult for the client that already needs to be able to = handle tokens anyway (bearer or not, both cases could occur). It's most= ly consolidating the logic.

    You're antici= pating a lot of issues which have no specific reason to occur, such as &quo= t;can't= be used with the token management APIs?". The management API is part = of the same general flow.
    Anticipating issues with rotation is useful= , but there are also many ways it can be hard to manage through a stateful = approach too. And fundamentally, having everything in a common model (both = for the internals of the AS and for the API calls) will help improve by a l= arge margin what is probably the weakest point in today's infrastructur= e. But it's early to be definitive as to the downstream impact either w= ay.=C2=A0 =C2=A0

    As for a persistent identifier instea= d of a continuation API, and generally the end of your message, it's a = totally unrelated issue to this PR, so I suggest we don't discuss that = here, but in a separate issue if needed.

    <= div>Fabien

    On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established that this is a differen= t access token, that requires different handling at the client. So keeping = it could cause more confusion?

    As an= RC, I will have to store the continue `uri` as although it could be static= it could also be dynamic. Why do I need to store an access token as well.= =C2=A0It brings me no benefit as an RC, in fact it brings more complexity. = As I will now need to manage multiple types of tokens with different lifecy= cles:

    Continuation token=C2=A0
    =C2=A0- may be rotated each time it is used, or= may not be
    =C2=A0- provided in the `continue` section of = the response
    =C2=A0- must be sender-constrained
    =C2=A0- can't be used with the token management APIs?
    =C2=A0- can be used to identify the grant when making subsequent gra= nts

    Access token(s) to use at RS
    =C2=A0= =C2=A0- can only be used at the specified RS
    =C2=A0 - may = be sender constrained
    =C2=A0 - when used at the RS, will n= ot result in rotation

    From my perspe= ctive, most use-cases will require the RC to have a persistent identifier f= or the grant. Why not bring this into the protocol and let the AS provide t= his persistent identifier (through the form of the continue uri). Using a r= otating access token as a persistent identifier doesn't seem like the r= ight choice.=C2=A0

    I see no security= benefit to having the continuation access token. It doesn't matter if = the continue uri leaks as it is useless without an accompanying signature, = i.e. any security benefit of having an access token is already provided by = having a signature.

    The only benefit= s that I can see are:
    =C2=A0- If the AS wants to be fully = stateless, then you can encode more data in a token than in a uri
    =C2=A0- If the AS wants to have a static endpoint for CRUD operatio= ns on the grant
    =C2=A0- To allow the AS to identity a prev= ious grant

    If we dropped the access = token for the continue endpoint and rather mandated a dynamic uri this woul= d make things conceptually easier to understand, easier for the RC to imple= ment, easier to debug and less chance of errors when rotating tokens (i.e. = race conditions could be quite likely if the AS always rotates the token)

    One-off grant with no continuation or ongoing manag= ement:
    RC sends signature and metadata, no `continue` = response provided, therefore no grant management possible
    Grant with ongoing management
    RC sends signa= ture and metadata, AS responds with a continue uri that has these purposes:=
    =C2=A0- can be used by the RC to continue/update, read or= revoke the grant
    =C2=A0- can be used by the RC when makin= g a new grant to identify the previous grant

    As an RC the only permanent items I need to store are:
    = =C2=A0- any access tokens I receive for the grant

    Dave

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Hi Torsten,=C2=A0

    You're= right on both accounts.=C2=A0
    - for the first remark, it fits qu= ite nicely the init request=C2=A0 / continuation pattern=C2=A0
    - = for the second remark, it is a sort of handle for the continuation=C2=A0req= uest, which will eventually lead to the issuance or refresh of standard acc= ess tokens=C2=A0

    Having a specific=C2=A0name is a = possibility, I actually suggested that too at some point.=C2=A0
    <= br>
    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderste= dt <torsten= @lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Techno= logy, 5th Floor, 10 Temple Back,= Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is a trading style of Moneyhub Fina= ncial Technology Limited which is authorised and regulated by the Financial= Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology is= entered on the Financial Services Register=C2=A0(FRN=C2= =A0809360) at https://register.fca.o= rg.uk/. Moneyhub=C2=A0Financial Technology is registered in England & Wales,= company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub= =C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    <= /span>
    DIS= CLAIMER: This email (including any attachments) is subject to copyright, an= d the information in it is confidential. Use of this email or of any inform= ation in it other than by the addressee is unauthorised and unlawful. Whils= t reasonable efforts are made to ensure that any attachments are virus-free= , it is the recipient's sole responsibility to scan all attachments for= viruses. All calls and emails to and from this company may be monitored an= d recorded for legitimate purposes relating to this company's business.= Any opinions expressed in this email (or in any attachments) are those of = the author and do not necessarily represent the opinions of Moneyhub Financ= ial Technology Limited or of any other group company.

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Techno= logy, 5th Floor, 10 Temple Back,= Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is a trading style of Moneyhub Fina= ncial Technology Limited which is authorised and regulated by the Financial= Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology is= entered on the Financial Services Register=C2=A0(FRN=C2= =A0809360) at https://register.fca.o= rg.uk/. Moneyhub=C2=A0Financial Technology is registered in England & Wales,= company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub= =C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    <= /span>
    DIS= CLAIMER: This email (including any attachments) is subject to copyright, an= d the information in it is confidential. Use of this email or of any inform= ation in it other than by the addressee is unauthorised and unlawful. Whils= t reasonable efforts are made to ensure that any attachments are virus-free= , it is the recipient's sole responsibility to scan all attachments for= viruses. All calls and emails to and from this company may be monitored an= d recorded for legitimate purposes relating to this company's business.= Any opinions expressed in this email (or in any attachments) are those of = the author and do not necessarily represent the opinions of Moneyhub Financ= ial Technology Limited or of any other group company.

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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



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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Techno= logy, 5th Floor, 10 Temple Back,= Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is a trading style of Moneyhub Fina= ncial Technology Limited which is authorised and regulated by the Financial= Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology is= entered on the Financial Services Register=C2=A0(FRN=C2= =A0809360) at https://register.fca.o= rg.uk/. Moneyhub=C2=A0Financial Technology is registered in England & Wales,= company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub= =C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    <= /span>
    DIS= CLAIMER: This email (including any attachments) is subject to copyright, an= d the information in it is confidential. Use of this email or of any inform= ation in it other than by the addressee is unauthorised and unlawful. Whils= t reasonable efforts are made to ensure that any attachments are virus-free= , it is the recipient's sole responsibility to scan all attachments for= viruses. All calls and emails to and from this company may be monitored an= d recorded for legitimate purposes relating to this company's business.= Any opinions expressed in this email (or in any attachments) are those of = the author and do not necessarily represent the opinions of Moneyhub Financ= ial Technology Limited or of any other group company.

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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





    --
    <= div dir=3D"ltr">
    Dave Tonge
    CTO
    3D"Mon=
    Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Mone= yhub Enterprise is a trading style of Moneyhub Financial Technology Limited= which is authorised and regulated by the Financial Conduct Authority (&quo= t;FCA").=C2=A0Moneyhub Financial Technology is entered on the Financia= l Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/. Moneyhub=C2=A0Financia= l Technology is registered in England & Wales, company registration num= ber=C2=A0=C2=A006909772= =C2=A0.=
    Moneyhub=C2=A0Financial Technology L= imited 2019=C2=A0=C2=A9<= /div>
    <= span style=3D"font-size:0.75em;font-family:lato,"open sans",arial= ,sans-serif;background-color:transparent">
    DISCLAIMER: This email (includi= ng any attachments) is subject to copyright, and the information in it is c= onfidential. Use of this email or of any information in it other than by th= e addressee is unauthorised and unlawful. Whilst reasonable efforts are mad= e to ensure that any attachments are virus-free, it is the recipient's = sole responsibility to scan all attachments for viruses. All calls and emai= ls to and from this company may be monitored and recorded for legitimate pu= rposes relating to this company's business. Any opinions expressed in t= his email (or in any attachments) are those of the author and do not necess= arily represent the opinions of Moneyhub Financial Technology Limited or of= any other group company.
    <= /div>

    Moneyhub Enterprise is a = trading style of Moneyhub Financial Technology Limited which is authorised = and regulated by the Financial Conduct Authority ("FCA"). Moneyhu= b Financial Technology is entered on the Financial Services Register (FRN 8= 09360) at https://register.fc= a.org.uk/. Moneyhub Financial Technology is registered in Englan= d & Wales, company registration number 06909772. Moneyhub Financial Tec= hnology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Qua= y, 1 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is subject to co= pyright, and the information in it is confidential. Use of this email or of= any information in it other than by the addressee is unauthorised and unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.




    --
    Dave = Tonge
    CTO
    3D"Moneyhub<= /div>
    Mo= neyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is= a trading style of Moneyhub Financial Technology Limited which is authoris= ed and regulated by the Financial Conduct Authority ("FCA").=C2= =A0Moneyhub Financial Technology is entered on the Financial Services Regis= ter=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/. Moneyhub=C2=A0F= inancial Technology is registered in England & Wales, company registrat= ion number=C2=A0=C2=A00= 6909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limit= ed 2019=C2=A0=C2=A9

    <= div style=3D"color:rgb(51,51,51);font-family:lato,"open sans",ari= al,sans-serif;font-size:14px;letter-spacing:normal;line-height:1.4">DISCLAIMER: This email (including any attachments) is subject to copyrig= ht, and the information in it is confidential. Use of this email or of any = information in it other than by the addressee is unauthorised and unlawful.= Whilst reasonable efforts are made to ensure that any attachments are viru= s-free, it is the recipient's sole responsibility to scan all attachmen= ts for viruses. All calls and emails to and from this company may be monito= red and recorded for legitimate purposes relating to this company's bus= iness. Any opinions expressed in this email (or in any attachments) are tho= se of the author and do not necessarily represent the opinions of Moneyhub = Financial Technology Limited or of any other group company.

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

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


    --00000000000086e60f05b6913b8f-- From nobody Wed Dec 16 02:15:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44283A083C for ; Wed, 16 Dec 2020 02:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VltXTN9JLd5w for ; Wed, 16 Dec 2020 02:15:39 -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 38A1E3A0992 for ; Wed, 16 Dec 2020 02:15:39 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id q137so23408764iod.9 for ; Wed, 16 Dec 2020 02:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aGodlhLgneJplhCjuiC6sjENa6W9p73v+vPLfYQH3bA=; b=seCNqbLdPXuN6fptPis7hIO0Zp4A3e+E+PYgWcP0vKkwNr2YSUE2vpYQG/bTowDSNL KEZ87ema4Cewp+3FiBqr98WtE5Y9rzQ+lz8tYqMmoxyFLWcipln9ck07b6dGvjujE0NR s9SrLHFaYe11j01lSwL5TGA95xS1AHN2ydXSI= 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=aGodlhLgneJplhCjuiC6sjENa6W9p73v+vPLfYQH3bA=; b=aDe76sC/mhheMwEsCM15vwNy9/c6Juqe9HC5GImyDJWiibGVy1vb0aUJKZenBFzwhp v8ZFMAlf2Mxw3pVKSXpfLstnQUugf76Yv4kzJsfnObsjcjIKfcQQyKXDYA6+NU/fa9gP KknQC5tAFpcOpDSVWwG58QHgbkJhfYCVObYzblCFiSNIzBniBP9kZ1ME1fyI66K7kuwt l22eNMx6nGgPnonfuASDyK+N6P6fPTc/5unTuONsTFIOUN8GzM1ekML3k83jM186Hjox zQM0uQm1+cFDJA1RoYNZ3D3yy2v2lexMrfygxSMhE/2Q4yz1UVD7KgkKnKKIz8Yeeql2 Cwuw== X-Gm-Message-State: AOAM530mK2k27/FTmTraVFl5SqRkGWTTUiwlIIVHF7sJjyyTws32Dwyz 3GvgyBjp9IOesPZ88isl4togJDp8UBmRn+ngv1dw X-Google-Smtp-Source: ABdhPJwjqT7n+FrvKAnT0iaiaforA9Q9chY5UoJfKgMAWwZOwHy86gd9LwQd4L21SP363WdNhtMxchvKscoB6BDTx1U= X-Received: by 2002:a5e:dc0d:: with SMTP id b13mr42400058iok.31.1608113737955; Wed, 16 Dec 2020 02:15:37 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> In-Reply-To: From: Warren Parad Date: Wed, 16 Dec 2020 11:15:26 +0100 Message-ID: To: Dave Tonge Cc: Dick Hardt , Fabien Imbault , Torsten Lodderstedt , txauth gnap , Justin Richer , Steve Moore Content-Type: multipart/alternative; boundary="0000000000001c17f905b692281f" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 16 Dec 2020 10:15:48 -0000 --0000000000001c17f905b692281f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable #4 is a prereq for this discussion though. If the token is the identifier of the grant then it must be in the url to avoid the problem of arbitrary url construction. Of course the uri would be *https://as/grants/{grantIdentifier} *. And this is actually independent of whether or not the token gets rotated. #3 The idea of a dynamic environment is important here, however the argument doesn't justify having this being the same endpoint. Nothing stops us from having two endpoints, one that requests an access token separate from the ones that manage the grant resource. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge wrote= : > > Dave: which points changed your mind? > > 1. The issue with re-using client authentication across endpoints in the > OAuth 2 world > (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods_= supported, introspection_endpoint_auth_methods_supported...) > > 2. The clear articulation of the 3 different functions of the AS > (including the idea of a self-hosted AS) > > 3. The aim to support a more dynamic environment where client > authentication only happens in the first interaction between the RC and t= he > AS > > 4. The agreement that there should be further discussion on whether this > access token should be rotated, and whether it should be an identifier of > the grant. > > > On Wed, 16 Dec 2020 at 00:02, Dick Hardt wrote: > >> Dave: which points changed your mind? >> >> On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge >> wrote: >> >>> Thanks for the detailed response. >>> >>> I think you make the points well and I'm now in favour of the PR. >>> However I do think that to keep the consistency that keeps being >>> discussed, that the tokens shouldn't be rotated. >>> >>> I also think it would be good to have a discussion about "grant >>> management" and identifiers for a grant. >>> >>> Dave >>> >>> On Tue, 15 Dec 2020 at 17:30, Justin Richer wrote: >>> >>>> On Dec 15, 2020, at 10:50 AM, Dave Tonge >>>> wrote: >>>> >>>> >>>> > The access token pattern has a lot of benefits, otherwise we >>>> wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>>> >>>> *But what are the benefits in this particular use case?* The >>>> continuation API is not like any other API - it is integral to the AS. >>>> There are quite a few extensions to OAuth that use client authenticati= on >>>> rather than access tokens. >>>> >>>> >>>> Yes, and the propagation of that has lead to a mess in the OAuth world= . >>>> You=E2=80=99ve got re-definitions of client authentications at all dif= ferent >>>> endpoints, they=E2=80=99re technically allowed to vary between endpoin= ts (though I >>>> don=E2=80=99t know of it happening in practice, that feels like a down= grade attack >>>> waiting to happen to someone). Then there=E2=80=99s the fact that all = the newest >>>> security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 d= on=E2=80=99t rely on client >>>> authentication at all to achieve security. All of these work without t= he >>>> client having credentials previously known to the AS, and we already k= now >>>> that GNAP is going to need to live in this more dynamic world. We need= to >>>> think beyond what OAuth 2 has done in the past, and especially from ou= r >>>> perceptions and assumptions of the models that drive OAuth 2=E2=80=99s= decisions, >>>> lest we repeat its mistakes. >>>> >>>> Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2= =80=9D as a point. >>>> In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the server side,= but in OAuth 2 we >>>> split that into the RS concept. Even though in practice, a lot of RS= =E2=80=99s are >>>> still integrated to the AS in some fashion because it=E2=80=99s a sing= le service, >>>> OAuth 2 is clear about what=E2=80=99s expected to be known by each com= ponent. For >>>> the AS as currently defined in GNAP, I=E2=80=99m seeing three distinct= functions. >>>> As per the Terminology discussion, we don=E2=80=99t have explicit name= s for these >>>> yet: >>>> >>>> - starting a request; this is an endpoint to kick things off; it need= s >>>> to be able to look up the rights asked for by the client (if it knows = the >>>> client at all ahead of time) and make initial decisions about needed >>>> interaction and follow up >>>> - continuing a request; this is an API that needs to know the context >>>> of the request itself, including which key it=E2=80=99s bound to; this= is separate >>>> from any identity of the client and possibly the user, but an AS >>>> implementation that has access to those elements can use them >>>> - interacting with the user; this is front-facing and in OAuth today >>>> is already deployed as a separate service in some places, we should em= brace >>>> that at the very least (but doing so formally is a separate issue) >>>> >>>> Why separate these in this way? There is immense power in having a >>>> single consistent way to start the process. The =E2=80=9Ccontinuation = API=E2=80=9D gives us >>>> an HTTP-defined mechanism for managing a request over time, including = the >>>> simple case of returning information from the front channel, but peopl= e >>>> have already raised the question of non-HTTP and self-hosted AS=E2=80= =99s, which >>>> would probably want a different kind of continuation API to communicat= e to >>>> the AS. The same thing with separating out the interaction: there are = going >>>> to be a lot of different ways to handle interaction out there, and not= all >>>> of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way that a= simple >>>> implementation might do. We=E2=80=99re defining a protocol based stron= gly on HTTP >>>> and JSON, but we should structure it in such a way that it can be exte= nded >>>> and translated elsewhere in a clear way. >>>> >>>> This all raises the question: if we can rely on a unique URL for >>>> redirect-based interaction, why not here? The simple reason is that a = URL >>>> is the :only: mechanism we have in the front channel for passing >>>> information, and we need to warn implementors against including sensit= ive >>>> information in it, and we need to protect it with additional items. We= have >>>> access to more than just URLs when we=E2=80=99re dealing with the cont= inuation API, >>>> and we ought to make use of all of our tools in ways that are consiste= nt >>>> and make sense. >>>> >>>> From a previous email the advantages I see are: >>>> - more data can be encoded in a token than in a uri (this seems more >>>> of an edge case) >>>> - it can be an identifier for the grant (I don't agree with this) >>>> >>>> >>>> It allows the parts above to live separately, even if they don=E2=80= =99t HAVE >>>> to. And it simplifies what we=E2=80=99re asking the client to do by ma= king it >>>> consistent with other parts of the ecosystem. The AS offering an API >>>> doesn=E2=80=99t :have: to be different, and OpenID Connect showed us, = with the >>>> UserInfo Endpoint, that that=E2=80=99s very much the case in practice. >>>> >>>> Having my client code do very similar things in slightly different way= s >>>> is not simpler. >>>> >>>> >>>> Another question I have: *do we envisage granting access tokens to the >>>> RC that will allow it to manage multiple grants*? >>>> >>>> >>>> I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t = been brought up >>>> as a use case to date. >>>> >>>> >>>> I also think there will be confusion with the signing being used for >>>> different things. Maybe it just needs to be called out in the spec tha= t: >>>> >>>> Request 1: signature =3D client authentication >>>> Request 2+: signature =3D proof of possession for access token >>>> >>>> >>>> That=E2=80=99s more or less the intent of what=E2=80=99s in the specif= ication right >>>> now, and why all the signature methods, which are used for both client= auth >>>> and token possession, are all together in section 8 and not separated = by >>>> use. (With the caveat: it=E2=80=99s only client authentication in the= first >>>> request if the AS knows about the client instance ahead of time, which >>>> isn=E2=80=99t always going to be true.) That all can likely be made cl= earer, as is >>>> always the case with spec text. But you can use the signature methods = with >>>> and without access tokens, and it only gets used without in an initial= call >>>> where you don=E2=80=99t :have: an access token to present. >>>> >>>> Separating the different kinds of =E2=80=9Cclient authentication" out = in OAuth >>>> is the source of some real confusion. Like right now, what happens if = you >>>> try to combine a client assertion, signed request objects for PAR, and= DPoP >>>> proofs, all in a single request? All of these are optional and all of = them >>>> =E2=80=9Cdo client authentication=E2=80=9D in some arguable fashion. I= =E2=80=99ve worked on several >>>> systems and implemented these things, and their interplay is really >>>> confusing to manage and can go sideways really fast. And that=E2=80=99= s just the >>>> work for a single endpoint, this gets repeated for introspection, >>>> revocation, CIBA, device, and on. >>>> >>>> At the end of the day I=E2=80=99m in favor of giving the client develo= pers a >>>> very clear set of directions on what they need to do and how they need= to >>>> access things, and treating the continuation as a token-bound API is, = to >>>> me, the clearest pattern we can offer for this piece. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, 15 Dec 2020 at 15:33, Justin Richer wrote: >>>> >>>>> I agree with Fabien that the persistent identifier is a separate >>>>> issue. The current spec re-uses the access token for this artifact, b= ut >>>>> that=E2=80=99s potentially brittle and could be changed out for somet= hing else. >>>>> There=E2=80=99s an issue asking for expanding on the use cases for th= is >>>>> functionality (which hasn=E2=80=99t been addressed by this PR): >>>>> >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>> >>>>> A potentially-rotating URI would be just as brittle, and so having a >>>>> single codified identifier for this artifact would be useful, but it = does >>>>> assume some things about the nature of the AS. Every other use the cl= ient >>>>> has to manage the ongoing request over time doesn=E2=80=99t need an e= xplicit >>>>> identifier. Just like with OAuth-protected APIs, the server can deter= mine >>>>> the context not just from the URI but from the rest of the request, >>>>> including the access token itself. This is both more common and more >>>>> powerful than a strict reading of REST designs. It also follows the H= ATEOS >>>>> principles as the entire HTTP request is taken into account, includin= g the >>>>> access token and signature portions. >>>>> >>>>> I=E2=80=99ll also point out that the rotation of these credentials is= also >>>>> filed as a separate issue that=E2=80=99s not being addressed right no= w, so we can >>>>> revisit that discussion separately: >>>>> >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>> >>>>> As for the name, we could give it a different label. We have this sam= e >>>>> pattern of issuing a resource-specific access token alongside a URL i= n the >>>>> Dynamic Registration specification, both in OAuth ( >>>>> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( >>>>> https://openid.net/specs/openid-connect-registration-1_0.html#Registr= ationResponse). >>>>> Here it=E2=80=99s called the =E2=80=9Cregistration access token=E2=80= =9D =E2=80=94 but what=E2=80=99s important >>>>> there, as it is here, is that it=E2=80=99s not a different kind of ar= tifact that >>>>> the client now has to figure out how to use, it=E2=80=99s an access t= oken plain and >>>>> simple. In the OAuth world this is a bearer token, since that=E2=80= =99s what OAuth >>>>> 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2= =80=99s what we=E2=80=99re >>>>> looking to build on. This is also related to another future discussio= n >>>>> about responses tying an access token to a specific API that=E2=80=99= s told to the >>>>> client, as we could potentially re-use those components and concepts = here >>>>> as well: >>>>> >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 >>>>> >>>>> And finally, no speculation on the complexity is needed: I implemente= d >>>>> this pattern several months ago during the design team discussions wh= en we >>>>> were considering this pattern, and the code is all online for people = to >>>>> see. >>>>> >>>>> https://github.com/bspk/oauth.xyz-java/ >>>>> >>>>> On the AS side, the most interesting code to this discussion is in th= e >>>>> TransactionEndpoint class: >>>>> >>>>> >>>>> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/i= o/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java >>>>> >>>>> Here, you=E2=80=99ll see that on initial request, the server looks up= the >>>>> client to see if it=E2=80=99s been registered, but after that, it mak= es sure that >>>>> the token and key are appropriate for the ongoing request. From the c= lient >>>>> side it=E2=80=99s even simpler. The client=E2=80=99s got a small serv= ice function to manage >>>>> the different signature methods that are implemented, and all of them= can >>>>> take in an optional access token: >>>>> >>>>> >>>>> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/i= o/bspk/oauth/xyz/http/SigningRestTemplateService.java >>>>> >>>>> The heavy lift is doing the actual signing, and you need that in orde= r >>>>> to start the process anyway. Managing the access token as an artifact= to >>>>> use at the API is completely trivial since the client already needs t= o >>>>> manage its own state internally to do any of this. And note that all = of >>>>> this is changed from how it was before: Previously, the XYZ Protocol = had >>>>> used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that t= he client would use to >>>>> continue the request. However, this simple model was limiting, and th= e >>>>> design team adopted XAuth=E2=80=99s model of continuation being an AP= I. In doing >>>>> so, we made it like all of the other APIs the client is going to call= : in >>>>> the initial state, it doesn=E2=80=99t have any kind of access rights,= it=E2=80=99s just >>>>> calling. From that initial call forward, the AS just needs to know th= at the >>>>> token and key match what it expects. >>>>> >>>>> In summary, my views are: >>>>> - The access token pattern has a lot of benefits, otherwise we >>>>> wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>>>> - Magic URIs have a lot of drawbacks which are well understood; whil= e >>>>> they can be mitigated, they can also be avoided >>>>> - Continuation is an API, and treating it like the other kinds of AP= I >>>>> the client would call makes sense >>>>> - Calling this by a special name, like =E2=80=9Cgrant access token= =E2=80=9D or >>>>> =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should fu= nction like any other >>>>> access token >>>>> - The heavy lift for clients is on protecting the message >>>>> cryptographically, which they need to do anyway >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> On Dec 15, 2020, at 7:50 AM, Dave Tonge >>>>> wrote: >>>>> >>>>> The persistent identifier is not a different issue, the current acces= s >>>>> token is used to reference an existing grant >>>>> >>>>> >>>>> >>>>> It may not be more difficult for a client to *use* an access token at >>>>> the AS / RS. But there is definitely an overhead on the client to >>>>> *manage* this separate access token. >>>>> >>>>> >>>>> >>>>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault >>>>> wrote: >>>>> >>>>>> I think we always said the access token was different, and handled a= s >>>>>> a bound token. >>>>>> >>>>>> But it doesn't mean it's more difficult for the client that already >>>>>> needs to be able to handle tokens anyway (bearer or not, both cases = could >>>>>> occur). It's mostly consolidating the logic. >>>>>> >>>>>> You're anticipating a lot of issues which have no specific reason to >>>>>> occur, such as "can't be used with the token management APIs?". The >>>>>> management API is part of the same general flow. >>>>>> Anticipating issues with rotation is useful, but there are also many >>>>>> ways it can be hard to manage through a stateful approach too. And >>>>>> fundamentally, having everything in a common model (both for the int= ernals >>>>>> of the AS and for the API calls) will help improve by a large margin= what >>>>>> is probably the weakest point in today's infrastructure. But it's ea= rly to >>>>>> be definitive as to the downstream impact either way. >>>>>> >>>>>> As for a persistent identifier instead of a continuation API, and >>>>>> generally the end of your message, it's a totally unrelated issue to= this >>>>>> PR, so I suggest we don't discuss that here, but in a separate issue= if >>>>>> needed. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>>>>> wrote: >>>>>> >>>>>>> So we've established that this is a different access token, that >>>>>>> requires different handling at the client. So keeping it could caus= e more >>>>>>> confusion? >>>>>>> >>>>>>> As an RC, I will have to store the continue `uri` as although it >>>>>>> could be static it could also be dynamic. Why do I need to store an= access >>>>>>> token as well. It brings me no benefit as an RC, in fact it brings = more >>>>>>> complexity. As I will now need to manage multiple types of tokens w= ith >>>>>>> different lifecycles: >>>>>>> >>>>>>> *Continuation token* >>>>>>> - can only be used at the continue endpoint (the name of which is >>>>>>> confusing as I can use this endpoint to revoke a grant or get metad= ata on >>>>>>> the grant). >>>>>>> - may be rotated each time it is used, or may not be >>>>>>> - provided in the `continue` section of the response >>>>>>> - must be sender-constrained >>>>>>> - can't be used with the token management APIs? >>>>>>> - can be used to identify the grant when making subsequent grants >>>>>>> >>>>>>> *Access token(s) to use at RS* >>>>>>> - can only be used at the specified RS >>>>>>> - may be sender constrained >>>>>>> - when used at the RS, will not result in rotation >>>>>>> >>>>>>> From my perspective, most use-cases will require the RC to have a >>>>>>> persistent identifier for the grant. Why not bring this into the pr= otocol >>>>>>> and let the AS provide this persistent identifier (through the form= of the >>>>>>> continue uri). Using a rotating access token as a persistent identi= fier >>>>>>> doesn't seem like the right choice. >>>>>>> >>>>>>> I see no security benefit to having the continuation access token. >>>>>>> It doesn't matter if the continue uri leaks as it is useless withou= t an >>>>>>> accompanying signature, i.e. any security benefit of having an acce= ss token >>>>>>> is already provided by having a signature. >>>>>>> >>>>>>> The only benefits that I can see are: >>>>>>> - If the AS wants to be fully stateless, then you can encode more >>>>>>> data in a token than in a uri >>>>>>> - If the AS wants to have a static endpoint for CRUD operations on >>>>>>> the grant >>>>>>> - To allow the AS to identity a previous grant >>>>>>> >>>>>>> If we dropped the access token for the continue endpoint and rather >>>>>>> mandated a dynamic uri this would make things conceptually easier t= o >>>>>>> understand, easier for the RC to implement, easier to debug and les= s chance >>>>>>> of errors when rotating tokens (i.e. race conditions could be quite= likely >>>>>>> if the AS always rotates the token) >>>>>>> >>>>>>> *One-off grant with no continuation or ongoing management:* >>>>>>> RC sends signature and metadata, no `continue` response provided, >>>>>>> therefore no grant management possible >>>>>>> >>>>>>> *Grant with ongoing management* >>>>>>> RC sends signature and metadata, AS responds with a continue uri >>>>>>> that has these purposes: >>>>>>> - can be used by the RC to continue/update, read or revoke the gra= nt >>>>>>> - can be used by the RC when making a new grant to identify the >>>>>>> previous grant >>>>>>> >>>>>>> As an RC the only permanent items I need to store are: >>>>>>> - the continue uri associated with the grant >>>>>>> - any access tokens I receive for the grant >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Torsten, >>>>>>>> >>>>>>>> You're right on both accounts. >>>>>>>> - for the first remark, it fits quite nicely the init request / >>>>>>>> continuation pattern >>>>>>>> - for the second remark, it is a sort of handle for the >>>>>>>> continuation request, which will eventually lead to the issuance o= r refresh >>>>>>>> of standard access tokens >>>>>>>> >>>>>>>> Having a specific name is a possibility, I actually suggested that >>>>>>>> too at some point. >>>>>>>> >>>>>>>> Fabien >>>>>>>> >>>>>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>>>>> torsten@lodderstedt.net> wrote: >>>>>>>> >>>>>>>>> Hi Fabien, >>>>>>>>> >>>>>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com>: >>>>>>>>> > >>>>>>>>> > Hi, >>>>>>>>> > >>>>>>>>> > On the contrary your feedback is most welcome. >>>>>>>>> > >>>>>>>>> > It doesn't accept any token, it needs the particular token as >>>>>>>>> described in 3.1 and which is not a bearer token (that's what the= "key" : >>>>>>>>> true parameter is supposed to convey). >>>>>>>>> > >>>>>>>>> > Let us know if you need more clarifications. >>>>>>>>> >>>>>>>>> Thanks for the clarification. I think only accepting this kind of >>>>>>>>> token at the continuation is a good idea otherwise the AS would n= eed to be >>>>>>>>> able to parse and understand all sorts of access tokens. >>>>>>>>> >>>>>>>>> Conceptually, I like the idea to treat the continuation as anothe= r >>>>>>>>> kind of resource. However, here are some observations I want to s= hare with >>>>>>>>> you: >>>>>>>>> - This resource is different as it will issue other access tokens >>>>>>>>> (of this kind) to be used in subsequent continuation requests. Th= is >>>>>>>>> requires different handing on the client side. >>>>>>>>> - This access token (if I understand correctly) is (or at least >>>>>>>>> feels like) a handle for the underlying grant. So it is kind of t= he super >>>>>>>>> access token to obtain other access tokens. >>>>>>>>> >>>>>>>>> I would consider using a different term to refer to this special >>>>>>>>> access token, grant token or grant handle for example, in order t= o prevent >>>>>>>>> confusion. >>>>>>>>> >>>>>>>>> best regards, >>>>>>>>> Torsten. >>>>>>>>> >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Best >>>>>>>>> > Fabien >>>>>>>>> > >>>>>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>>>>> > Hi all, >>>>>>>>> > >>>>>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me ques= tion >>>>>>>>> seems naive. >>>>>>>>> > >>>>>>>>> > After having skimmed through the current draft and the PR, I=E2= =80=98m >>>>>>>>> not sure whether the continuation requests accepts any access tok= en issued >>>>>>>>> to the RC or the particular access token returned in the =E2=80= =9Econtinue=E2=80=9C element >>>>>>>>> in section 3.1.. >>>>>>>>> > >>>>>>>>> > Can you please shed some light on this? >>>>>>>>> > >>>>>>>>> > kind regards, >>>>>>>>> > Torsten. >>>>>>>>> > >>>>>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com>: >>>>>>>>> >> >>>>>>>>> >> =EF=BB=BF >>>>>>>>> >> You're completely right. Allowing the dev to be lazy is a very >>>>>>>>> good thing in general, because it's what we know will work :-) >>>>>>>>> >> >>>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore >>>>>>>>> a =C3=A9crit : >>>>>>>>> >> Hi Fabien, >>>>>>>>> >> >>>>>>>>> >> For #3) Even after I typed out the hypothetical attack, that >>>>>>>>> was sort of in the back of my mind, it isn't a huge risk there. S= o I >>>>>>>>> actually agree with Dick there. Something doesn't sit right with = me for the >>>>>>>>> unique URL solution, so I don't like it and came up with a hypoth= etical >>>>>>>>> that seems like it could be a down side. >>>>>>>>> >> >>>>>>>>> >> I still think the access token model with the signed request i= s >>>>>>>>> the way I'd like to go, because again, it's a mechanism I'd be im= plementing >>>>>>>>> anyway to talk to any 'normal' resource. The fact is there is _so= mething_ >>>>>>>>> representing context that has to pass back and forth here, whethe= r that is >>>>>>>>> an access token (which I feel like is more flexible for extension= s etc), a >>>>>>>>> unique url, or even a cookie sent in the cookie header. So just t= o >>>>>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy dev= eloper ;) >>>>>>>>> >> -steve >>>>>>>>> >> >>>>>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>> >> Again speaking in my own name here. >>>>>>>>> >> >>>>>>>>> >> Dick, we know you'd prefer to have a different design, but thi= s >>>>>>>>> PR shouldn't be about that. >>>>>>>>> >> >>>>>>>>> >> Back on your 3 items : >>>>>>>>> >> >>>>>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>>>>> decided that wouldn't be how that would work. We have a client in= stance >>>>>>>>> that allows a more generic and flexible pattern (which BTW also a= llows what >>>>>>>>> you want) >>>>>>>>> >> >>>>>>>>> >> 2) instead of blame arguments of who's less >>>>>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversat= ions, I >>>>>>>>> suggest we speak in less abstract terms and ask ourselves what th= at means >>>>>>>>> in practice for devs. Stephen and several others (myself included= ) have >>>>>>>>> expressed that it wouldn't be harder to implement, it would even = simplify >>>>>>>>> things quite a lot. If you disagree please send us a code sample = to really >>>>>>>>> show that point by example, because that's really not obvious. >>>>>>>>> >> >>>>>>>>> >> 3) "If someone has the client credentials, they can impersonat= e >>>>>>>>> the client, and all bets are off." Are you seriously making this = argument? >>>>>>>>> Because if you have a better proposal than using cryptographic ke= ys, I'm >>>>>>>>> all hears. You make it look like there's a problem, while in real= ity we're >>>>>>>>> only relying on the basic assumption of all modern digital commun= ications. >>>>>>>>> >> >>>>>>>>> >> And more importantly you never responded to the issues of how >>>>>>>>> to avoid the security pitfalls of what you proposed. >>>>>>>>> >> >>>>>>>>> >> Fabien >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt >>>>>>>>> a =C3=A9crit : >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore < >>>>>>>>> srmoore@gmail.com> wrote: >>>>>>>>> >> But from the spec: >>>>>>>>> >> " >>>>>>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>>>>>> identify itself by including the client field of the request... >>>>>>>>> >> ... >>>>>>>>> >> key (object / string) : The public key of the RC to be used in >>>>>>>>> this request as described in {{request-key}}. This field is REQUI= RED. >>>>>>>>> >> ... >>>>>>>>> >> " >>>>>>>>> >> So on the initial request, the key will be there. >>>>>>>>> >> >>>>>>>>> >> The client field can be an object or a string. If the client i= s >>>>>>>>> pre-registered, then a string could be provided instead of an obj= ect. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> If you don't have the access token, then how do you >>>>>>>>> differentiate between two requests from the same web application = by two >>>>>>>>> different users? Is the web application supposed to have differen= t >>>>>>>>> credentials for every request? >>>>>>>>> >> >>>>>>>>> >> The AS returns a URI for manipulating the request. I would >>>>>>>>> change the spec so that each request would have a unique URI. Thi= s is the >>>>>>>>> usually RESTful pattern that the resource (the grant request) has= an URI. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> So in this case, the easy way out is to pass the access token >>>>>>>>> to the client, who then, as i stated before, treats the continue = request as >>>>>>>>> a RS call (albeit a specialized version of the RS where the RS is= the AS) >>>>>>>>> OR to use the unique URL, >>>>>>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>>>>>> (What would be the point of that attack, I don't know, I guess if= someone >>>>>>>>> had the client credentials but not any subjects/resources they co= uld try to >>>>>>>>> intercept the grant via continue... I just don't feel right locki= ng things >>>>>>>>> down to unique URLs that way.) >>>>>>>>> >> >>>>>>>>> >> If someone has the client credentials, they can impersonate th= e >>>>>>>>> client, and all bets are off. >>>>>>>>> >> >>>>>>>>> >> LOTS of RS servers return a resource specific URL -- my >>>>>>>>> proposal is no different. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> -steve >>>>>>>>> >> >>>>>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt < >>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>> >> Hi Stephen >>>>>>>>> >> >>>>>>>>> >> The client is signing the first request. The key *might* be in >>>>>>>>> the body. The client is signing all the subsequent requests as we= ll. The >>>>>>>>> "access token" is not needed by the client to prove it is authori= zed as the >>>>>>>>> client is proving it is the same client again. >>>>>>>>> >> >>>>>>>>> >> In other words, I don't see the need for an access token, so i= t >>>>>>>>> does not need to be put in a URL or an auth header. >>>>>>>>> >> >>>>>>>>> >> If a developer really, really wants to hand context back to th= e >>>>>>>>> client for subsequent calls, they can put it in the URL or some o= ther >>>>>>>>> method. Putting it in the HTTP Authorization header is confusing = because it >>>>>>>>> is NOT an access token -- it is the context of the request. >>>>>>>>> >> >>>>>>>>> >> =E1=90=A7 >>>>>>>>> >> >>>>>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore < >>>>>>>>> srmoore@gmail.com> wrote: >>>>>>>>> >> Even though I've only been lightly following things, I feel th= e >>>>>>>>> need to voice my preference as a developer since I will probably = someday >>>>>>>>> have to either write a RC or RS... >>>>>>>>> >> >>>>>>>>> >> The way I see it is the RC makes the initial request to the AS >>>>>>>>> as part of this request, it provides it's key in the body... (So = no use of >>>>>>>>> the Authorization header) >>>>>>>>> >> At this point that request, represented by the continue URL + >>>>>>>>> "Access Token", from my lazy developer standpoint, is a Resource = Endpoint >>>>>>>>> and Access Token, and the AS is acting as a specialized RS in thi= s case. >>>>>>>>> >> So my client posts to whatever URL with the 'access token' in >>>>>>>>> the authorization header, just like acting on any other resource = I have a >>>>>>>>> token for. YES, I get a new token value to use every call, and th= ere is a >>>>>>>>> decision point of "Do I have another continue, or do I have a rea= l token >>>>>>>>> for the resource..." But the mechanism is the same to me in the c= lient. >>>>>>>>> >> Personally I like that, because if I have an access_token, I >>>>>>>>> already think "Put it in the auth header." >>>>>>>>> >> >>>>>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>>>>> >> -steve >>>>>>>>> >> >>>>>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt < >>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>> >> inline ... >>>>>>>>> >> >>>>>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>>>> wrote: >>>>>>>>> >> Others had already responded to this previous thread, but I >>>>>>>>> wanted to add a couple points to clarify some things. >>>>>>>>> >> >>>>>>>>> >>> 3) What the client has to do with the "access token" is not >>>>>>>>> the same as access tokens for an RS. The client gets a new "acces= s token" >>>>>>>>> for each grant request, and for each API call to the AS, and the = client >>>>>>>>> learns it can not make any more API calls for that specific reque= st when it >>>>>>>>> does not get an "access token" back. This is a completely differe= nt design >>>>>>>>> pattern than calling an RS API with an access token, and is a new= design >>>>>>>>> pattern for calling APIs. This adds complexity to the client that= it would >>>>>>>>> not normally have, and I don't think GNAP is the right place to s= tart a new >>>>>>>>> design pattern. >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> >> I=E2=80=99m not sure what you mean by these being different = =E2=80=94 the whole >>>>>>>>> point of the design is that the client would be doing the same th= ing with >>>>>>>>> the access token at the AS that it does with the RS by re-using t= he access >>>>>>>>> token structure. Can you please describe what the differences are= , apart >>>>>>>>> from the rotation? Presentation of the token and signing of the m= essage are >>>>>>>>> identical. >>>>>>>>> >> >>>>>>>>> >> The client is getting the "access token" from its API. It is >>>>>>>>> not using an "access_token" in other API calls to the AS. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>>>>> continuation responses is a separate issue to be discussed: >>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>>>> >> >>>>>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right = place to >>>>>>>>> have new designs =E2=80=94 not that this is one. >>>>>>>>> >> >>>>>>>>> >> You are proposing a new way for an API to provide context for >>>>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >>> 4) Clients that only want claims from the AS and no access >>>>>>>>> tokens will be required to support an API calling mechanism they = would not >>>>>>>>> have to support otherwise. >>>>>>>>> >> >>>>>>>>> >> Correct, but the delta between the calls a client would make >>>>>>>>> with and without an access token is vanishingly small. The client= has to >>>>>>>>> sign the initial request in some fashion, and it will sign the co= ntinuation >>>>>>>>> request in the same exact fashion, but now include an access toke= n in that >>>>>>>>> request. >>>>>>>>> >> >>>>>>>>> >> Per my other point, there is no value to me in my >>>>>>>>> implementations of passing context back and forth between the cli= ent and AS >>>>>>>>> -- so it is extra work providing no value. >>>>>>>>> >> >>>>>>>>> >> Also, any client authentication mechanism that wants to use th= e >>>>>>>>> HTTP Authentication header is precluded from using it. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Clients making a request to an AS and not getting an access >>>>>>>>> token is a new design pattern. I think it has value and should be= included, >>>>>>>>> but OAuth today shows us the immense value of getting access toke= ns for >>>>>>>>> calling APIs, and so we shouldn=E2=80=99t optimize away from that= pattern. >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>>>>> mechanism for a client to delete the request, as the client is no= t allowed >>>>>>>>> to make a call without an "access token". >>>>>>>>> >> >>>>>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue= =E2=80=9D field >>>>>>>>> then the client can=E2=80=99t delete the request =E2=80=94 and ye= s, that=E2=80=99s intentional. The >>>>>>>>> AS is telling this client instance that it can=E2=80=99t do anyth= ing else with this >>>>>>>>> ongoing request. If the AS wants to allow the client to manage it= , it will >>>>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D= field. >>>>>>>>> >> >>>>>>>>> >> There is nuance in that intention. A related concern is that >>>>>>>>> deleting a request does not seem like it is a "continue" operatio= n. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>> >>> 6) There is no standard identifier for the request. Debugging >>>>>>>>> and auditing are hampered by the client and AS having no standard= way to >>>>>>>>> identifying a request. While one AS may provide a unique URL for = each grant >>>>>>>>> request, another AS may use a persistent "access token" to identi= fy the >>>>>>>>> grant request, and other ASs may issue a new "access token" on ea= ch API >>>>>>>>> call, providing no persistent identifier for the request. >>>>>>>>> >> >>>>>>>>> >> Debugging and auditing this kind of thing are functions of the >>>>>>>>> AS. How is interoperability harmed by different ASs having differ= ent >>>>>>>>> methods to identify their internal data elements? The client does= n=E2=80=99t need >>>>>>>>> any knowledge of the AS=E2=80=99s identifiers, it just needs to k= now the next steps >>>>>>>>> for continuing the negotiation. >>>>>>>>> >> >>>>>>>>> >> Debugging between the client and the AS was what I was >>>>>>>>> referring to. How does a client developer identify the request wh= en >>>>>>>>> communicating to the AS developer. Seems complicated. >>>>>>>>> >> >>>>>>>>> >> =E1=90=A7 >>>>>>>>> >> -- >>>>>>>>> >> TXAuth mailing list >>>>>>>>> >> TXAuth@ietf.org >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >> =E1=90=A7 >>>>>>>>> >> -- >>>>>>>>> >> TXAuth mailing list >>>>>>>>> >> TXAuth@ietf.org >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >> -- >>>>>>>>> >> TXAuth mailing list >>>>>>>>> >> TXAuth@ietf.org >>>>>>>>> >> >>>>>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listi= nfo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qV= Ou0IQPJJYtSpI >>>>>>>>> >>>>>>>>> -- >>>>>>>> TXAuth mailing list >>>>>>>> TXAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dave Tonge >>>>>>> CTO >>>>>>> [image: Moneyhub Enterprise] >>>>>>> >>>>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>>>> BS1 6FL >>>>>>> >>>>>>> t: +44 (0)117 280 5120 >>>>>>> >>>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>>> Technology Limited which is authorised and regulated by the Financi= al >>>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the >>>>>>> Financial Services Register (FRN 809360) at *https://register.fca.o= rg.uk/ >>>>>>> *. Moneyhub Financial Technology is >>>>>>> registered in England & Wales, company registration number 0690977= 2 >>>>>>> . >>>>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>>>> >>>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>>> copyright, and the information in it is confidential. Use of this e= mail or >>>>>>> of any information in it other than by the addressee is unauthorise= d and >>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any att= achments >>>>>>> are virus-free, it is the recipient's sole responsibility to scan a= ll >>>>>>> attachments for viruses. All calls and emails to and from this comp= any may >>>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>>> company's business. Any opinions expressed in this email (or in any >>>>>>> attachments) are those of the author and do not necessarily represe= nt the >>>>>>> opinions of Moneyhub Financial Technology Limited or of any other g= roup >>>>>>> company. >>>>>>> >>>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>>> Technology Limited which is authorised and regulated by the Financi= al >>>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the >>>>>>> Financial Services Register (FRN 809360) at >>>>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>>>> registered in England & Wales, company registration number 06909772= . >>>>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterpri= se, Regus >>>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>>>> >>>>>>> . >>>>>>> >>>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>>> copyright, and the information in it is confidential. Use of this e= mail or >>>>>>> of any information in it other than by the addressee is unauthorise= d and >>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any att= achments >>>>>>> are virus-free, it is the recipient's sole responsibility to scan a= ll >>>>>>> attachments for viruses. All calls and emails to and from this comp= any may >>>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>>> company's business. Any opinions expressed in this email (or in any >>>>>>> attachments) are those of the author and do not necessarily represe= nt the >>>>>>> opinions of Moneyhub Financial Technology Limited or of any other g= roup >>>>>>> company. >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Dave Tonge >>>>> CTO >>>>> [image: Moneyhub Enterprise] >>>>> >>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>> BS1 6FL >>>>> >>>>> t: +44 (0)117 280 5120 >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at *https://register.fca.org= .uk/ >>>>> *. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772 = . >>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at >>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772. >>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise= , Regus >>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>> >>>>> . >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> >>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>>> -- >>>> Dave Tonge >>>> CTO >>>> [image: Moneyhub Enterprise] >>>> >>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>>> 6FL >>>> >>>> t: +44 (0)117 280 5120 >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at *https://register.fca.org.= uk/ >>>> *. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772 . >>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>> >>>> . >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >>>> >>> >>> -- >>> Dave Tonge >>> CTO >>> [image: Moneyhub Enterprise] >>> >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>> 6FL >>> >>> t: +44 (0)117 280 5120 >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at *https://register.fca.org.u= k/ >>> *. Moneyhub Financial Technology is >>> registered in England & Wales, company registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, >>> BS1 6EA >>> >>> . >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001c17f905b692281f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    #4 is a prereq for this discussion though. If the token is= the identifier of the grant then it must be in the url to avoid the proble= m of arbitrary url construction. Of course the uri would be https://as/grants/{grantIdentifier}= . And this is actually independent of whether or not the token gets rot= ated.

    #3 The idea of a dynamic environment is impor= tant here, however the argument doesn't justify having this being the s= ame endpoint. Nothing stops us from having two endpoints, one that requests= an access token separate from the ones that manage the grant resource.

    <= img src=3D"https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXs= qhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY= -nh6hjuIm9GCeBRRzrSc8kWcUSNtuA" width=3D"199" height=3D"34" style=3D"margin= -left: 0px; margin-top: 0px;">

    Warren Parad

    Founder, CTO

    Secure y= our user data and complete your authorization architecture. Implement=C2=A0= Authress.


    On Wed, Dec 16, 2020 at 10:09 AM Dave T= onge <dave.tonge@moneyhub.com= > wrote:
    =
    >=C2=A0Dave: which points changed your mind?
    <= br>
    1. The issue with re-using client authentication acro= ss endpoints in the OAuth 2 world (token_endpoint_auth_methods_supported,= =C2=A0revocation_endpoint_auth_methods_supported,=C2=A0introspection_endpoi= nt_auth_methods_supported...)

    2. The clear articulation of the 3 different functions of the= AS (including the idea of a self-hosted AS)
    3. The aim to support a more dynamic en= vironment where client authentication only happens in the first interaction= between the RC and the AS

    4. The ag= reement that there should be further discussion on whether this access toke= n should be rotated, and whether it should be an identifier of the grant.

    On Wed, 16 Dec 2020 at 00:02, Dick Hardt <dick.hardt@gmail.com> wr= ote:
    Dave: which points changed your mind?

    On Tue, Dec 15, 2020 at 1:= 11 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    Thanks for the d= etailed response.

    I think you make t= he points well and I'm now in favour of the PR.
    Howeve= r I do think that to keep the consistency that keeps being discussed, that = the tokens shouldn't be rotated.=C2=A0

    I also think it would be good to have a discussion about "grant= management" and identifiers for a grant.
    =

    Dave

    On Tue, 15 Dec 2020 at 17:30, J= ustin Richer <jrich= er@mit.edu> wrote:
    On Dec 15, 2020, at 10:50 AM, Dave Tonge <dave.tonge@moneyhub.com&= gt; wrote:

    >=C2=A0Th= e access token pattern has a lot of benefits, otherwise we wouldn=E2=80=99t= have an entire OAuth ecosystem based on it

    But what are the benefits=C2=A0in this particular use= case? The continuation API is not like any other API - it is integral = to the AS. There are quite a few extensions to OAuth that use client authen= tication rather than access tokens.

    =
    Yes, and the propagation of that has lead to a mess in the OAuth= world. You=E2=80=99ve got re-definitions of client authentications at all = different endpoints, they=E2=80=99re technically allowed to vary between en= dpoints (though I don=E2=80=99t know of it happening in practice, that feel= s like a downgrade attack waiting to happen to someone). Then there=E2=80= =99s the fact that all the newest security mechanisms we have =E2=80=94 PKC= E, DPoP, and MTLS =E2=80=94 don=E2=80=99t rely on client authentication at = all to achieve security. All of these work without the client having creden= tials previously known to the AS, and we already know that GNAP is going to= need to live in this more dynamic world. We need to think beyond what OAut= h 2 has done in the past, and especially from our perceptions and assumptio= ns of the models that drive OAuth 2=E2=80=99s decisions, lest we repeat its= mistakes.=C2=A0

    Also, I want to challenge this id= ea of =E2=80=9Cintegral to the AS=E2=80=9D as a point. In OAuth 1, the API = was =E2=80=9Cintegral=E2=80=9D to the server side, but in OAuth 2 we split = that into the RS concept. Even though in practice, a lot of RS=E2=80=99s ar= e still integrated to the AS in some fashion because it=E2=80=99s a single = service, OAuth 2 is clear about what=E2=80=99s expected to be known by each= component. For the AS as currently defined in GNAP, I=E2=80=99m seeing thr= ee distinct functions. As per the Terminology discussion, we don=E2=80=99t = have explicit names for these yet:

    =C2=A0- startin= g a request; this is an endpoint to kick things off; it needs to be able to= look up the rights asked for by the client (if it knows the client at all = ahead of time) and make initial decisions about needed interaction and foll= ow up
    =C2=A0- continuing a request; this is an API that needs to know = the context of the request itself, including which key it=E2=80=99s bound t= o; this is separate from any identity of the client and possibly the user, = but an AS implementation that has access to those elements can use them
    =C2=A0- interacting with the user; this is front-facing and in OAuth= today is already deployed as a separate service in some places, we should = embrace that at the very least (but doing so formally is a separate issue)<= /div>

    Why separate these in this way? There is immense p= ower in having a single consistent way to start the process. The =E2=80=9Cc= ontinuation API=E2=80=9D gives us an HTTP-defined mechanism for managing a = request over time, including the simple case of returning information from = the front channel, but people have already raised the question of non-HTTP = and self-hosted AS=E2=80=99s, which would probably want a different kind of= continuation API to communicate to the AS. The same thing with separating = out the interaction: there are going to be a lot of different ways to handl= e interaction out there, and not all of them will be =E2=80=9Cintegral=E2= =80=9D to the AS in the way that a simple implementation might do. We=E2=80= =99re defining a protocol based strongly on HTTP and JSON, but we should st= ructure it in such a way that it can be extended and translated elsewhere i= n a clear way.

    This all raises the question: if we can rely on = a unique URL for redirect-based interaction, why not here? The simple reaso= n is that a URL is the :only: mechanism we have in the front channel for pa= ssing information, and we need to warn implementors against including sensi= tive information in it, and we need to protect it with additional items. We= have access to more than just URLs when we=E2=80=99re dealing with the con= tinuation API, and we ought to make use of all of our tools in ways that ar= e consistent and make sense.

    From a previous ema= il the advantages I see are:
    =C2=A0- more= data can be encoded in a token than in a uri (this seems more of an edge c= ase)
    =C2=A0- it can be an identifier for = the grant (I don't agree with this)
    =
    It allows the parts above to live separately, even if they d= on=E2=80=99t HAVE to. And it simplifies what we=E2=80=99re asking the clien= t to do by making it consistent with other parts of the ecosystem. The AS o= ffering an API doesn=E2=80=99t :have: to be different, and OpenID Connect s= howed us, with the UserInfo Endpoint, that that=E2=80=99s very much the cas= e in practice.=C2=A0

    Having my client code do very= similar things in slightly different ways is not simpler.


    <= /div>
    Another question I have: do we envisag= e granting access tokens to the RC that will allow it to manage multiple gr= ants?=C2=A0=C2=A0

    I d= on=E2=80=99t see that happening, personally, and it hasn=E2=80=99t been bro= ught up as a use case to date.=C2=A0


    I also think there will be confusion with the signing being use= d for different things. Maybe it just needs to be called out in the spec th= at:

    Request 1: signature =3D client authentication
    Request 2+: signature =3D proof of possession for access token<= /div>

    <= br>
    That=E2=80=99s more or less the intent of what=E2=80=99s in t= he specification right now, and why all the signature methods, which are us= ed for both client auth and token possession, are all together in section 8= and not separated by use. =C2=A0(With the caveat: it=E2=80=99s only client= authentication in the first request if the AS knows about the client insta= nce ahead of time, which isn=E2=80=99t always going to be true.) That all c= an likely be made clearer, as is always the case with spec text. But you ca= n use the signature methods with and without access tokens, and it only get= s used without in an initial call where you don=E2=80=99t :have: an access = token to present.

    Separating the different kinds o= f =E2=80=9Cclient authentication" out in OAuth is the source of some r= eal confusion. Like right now, what happens if you try to combine a client = assertion, signed request objects for PAR, and DPoP proofs, all in a single= request? All of these are optional and all of them =E2=80=9Cdo client auth= entication=E2=80=9D in some arguable fashion. I=E2=80=99ve worked on severa= l systems and implemented these things, and their interplay is really confu= sing to manage and can go sideways really fast. And that=E2=80=99s just the= work for a single endpoint, this gets repeated for introspection, revocati= on, CIBA, device, and on.

    At the end of the day I= =E2=80=99m in favor of giving the client developers a very clear set of dir= ections on what they need to do and how they need to access things, and tre= ating the continuation as a token-bound API is, to me, the clearest pattern= we can offer for this piece.

    =C2=A0=E2=80=94 Just= in








    <= /div>

    On Tue, 15 Dec 2020 at 15:33, Justin Richer <jricher@mit.edu> wrote:
    I agree with Fabien that= the persistent identifier is a separate issue. The current spec re-uses th= e access token for this artifact, but that=E2=80=99s potentially brittle an= d could be changed out for something else. There=E2=80=99s an issue asking = for expanding on the use cases for this functionality (which hasn=E2=80=99t= been addressed by this PR):


    A = potentially-rotating URI would be just as brittle, and so having a single c= odified identifier for this artifact would be useful, but it does assume so= me things about the nature of the AS. Every other use the client has to man= age the ongoing request over time doesn=E2=80=99t need an explicit identifi= er. Just like with OAuth-protected APIs, the server can determine the conte= xt not just from the URI but from the rest of the request, including the ac= cess token itself. This is both more common and more powerful than a strict= reading of REST designs. It also follows the HATEOS principles as the enti= re HTTP request is taken into account, including the access token and signa= ture portions.=C2=A0

    I=E2=80=99ll also point out t= hat the rotation of these credentials is also filed as a separate issue tha= t=E2=80=99s not being addressed right now, so we can revisit that discussio= n separately:


    As for the = name, we could give it a different label. We have this same pattern of issu= ing a resource-specific access token alongside a URL in the Dynamic Registr= ation specification, both in OAuth (https://tools.ietf.org/html/rfc7592#se= ction-3) and OpenID Connect (http= s://openid.net/specs/openid-connect-registration-1_0.html#RegistrationRespo= nse). Here it=E2=80=99s called the =E2=80=9Cregistration access token= =E2=80=9D =E2=80=94 but what=E2=80=99s important there, as it is here, is t= hat it=E2=80=99s not a different kind of artifact that the client now has t= o figure out how to use, it=E2=80=99s an access token plain and simple. In = the OAuth world this is a bearer token, since that=E2=80=99s what OAuth 2 u= ses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2=80=99s wh= at we=E2=80=99re looking to build on. This is also related to another futur= e discussion about responses tying an access token to a specific API that= =E2=80=99s told to the client, as we could potentially re-use those compone= nts and concepts here as well:

    And finally, no speculation on the complexity is needed: I impl= emented this pattern several months ago during the design team discussions = when we were considering this pattern, and the code is all online for peopl= e to see.=C2=A0


    On the AS side, the most interesting code to = this discussion is in the TransactionEndpoint class:

    https://github.com/bspk/oauth.xyz-java/blob/master/as/src/mai= n/java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java

    Here, you=E2=80=99ll see that on initial request, t= he server looks up the client to see if it=E2=80=99s been registered, but a= fter that, it makes sure that the token and key are appropriate for the ong= oing request. From the client side it=E2=80=99s even simpler. The client=E2= =80=99s got a small service function to manage the different signature meth= ods that are implemented, and all of them can take in an optional access to= ken:=C2=A0


    The heavy lift is doing the actual= signing, and you need that in order to start the process anyway. Managing = the access token as an artifact to use at the API is completely trivial sin= ce the client already needs to manage its own state internally to do any of= this. And note that all of this is changed from how it was before: Previou= sly, the XYZ Protocol had used a =E2=80=9Ctransaction handle=E2=80=9D retur= ned by the AS that the client would use to continue the request. However, t= his simple model was limiting, and the design team adopted XAuth=E2=80=99s = model of continuation being an API. In doing so, we made it like all of the= other APIs the client is going to call: in the initial state, it doesn=E2= =80=99t have any kind of access rights, it=E2=80=99s just calling. From tha= t initial call forward, the AS just needs to know that the token and key ma= tch what it expects.=C2=A0

    In summary, my views ar= e:
    =C2=A0- The access token pattern has a lot of benefits, otherw= ise we wouldn=E2=80=99t have an entire OAuth ecosystem based on it
    =C2=A0- Magic URIs have a lot of drawbacks which are well understood; whi= le they can be mitigated, they can also be avoided
    =C2=A0- Contin= uation is an API, and treating it like the other kinds of API the client wo= uld call makes sense
    =C2=A0- Calling this by a special name, like= =E2=80=9Cgrant access token=E2=80=9D or =E2=80=9Ccontinuation access token= =E2=80=9D is fine, but it should function like any other access token
    =
    =C2=A0- The heavy lift for clients is on protecting the message crypto= graphically, which they need to do anyway

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


    On D= ec 15, 2020, at 7:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    <= div>
    The persistent identifier=C2=A0is not a di= fferent issue, the current access token is used to reference an= existing grant=C2=A0

    It may not= be more difficult for a client to use an access token at the AS / RS. But there=C2= =A0is definitely an overhead on the client to manage=C2=A0this separate access token.= =C2=A0



    On Tue, 15 Dec 2020= at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I think we always= said the access token was different, and handled as a bound token.
    But it doesn't mean it's more difficult for the client = that already needs to be able to handle tokens anyway (bearer or not, both = cases could occur). It's mostly consolidating the logic.

    You're anticipating a lot of issues which have no speci= fic reason to occur, such as "can't be used with the token management APIs?&q= uot;. The management API is part of the same general flow.
    Anticipati= ng issues with rotation is useful, but there are also many ways it can be h= ard to manage through a stateful approach too. And fundamentally, having ev= erything in a common model (both for the internals of the AS and for the AP= I calls) will help improve by a large margin what is probably the weakest p= oint in today's infrastructure. But it's early to be definitive as = to the downstream impact either way.=C2=A0 =C2=A0

    As f= or a persistent identifier instead of a continuation API, and generally the= end of your message, it's a totally unrelated issue to this PR, so I s= uggest we don't discuss that here, but in a separate issue if needed.

    Fabien

    On Tue, Dec 15, 2020 at 11= :08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've = established that this is a different access token, that requires different = handling at the client. So keeping it could cause more confusion?

    As an RC, I will have to store the continue `= uri` as although it could be static it could also be dynamic. Why do I need= to store an access token as well.=C2=A0It brings me no benefit as an RC, i= n fact it brings more complexity. As I will now need to manage multiple typ= es of tokens with different lifecycles:

    Continuati= on token=C2=A0
    =C2=A0 - can only be used at the contin= ue endpoint (the name of which is confusing as I can use this endpoint to r= evoke a grant or get metadata on the grant).
    =C2=A0- may b= e rotated each time it is used, or may not be
    =C2=A0- prov= ided in the `continue` section of the response
    =C2=A0- mus= t be sender-constrained
    =C2=A0- can't be used with the= token management APIs?
    =C2=A0- can be used to identify th= e grant when making subsequent grants

    Access token= (s) to use at RS
    =C2=A0=C2=A0- can only be used at the specified= RS
    =C2=A0 - may be sender constrained
    = =C2=A0 - when used at the RS, will not result in rotation
    From my perspective, most use-cases will require th= e RC to have a persistent identifier for the grant. Why not bring this into= the protocol and let the AS provide this persistent identifier (through th= e form of the continue uri). Using a rotating access token as a persistent = identifier doesn't seem like the right choice.=C2=A0
    <= br>
    I see no security benefit to having the continuation a= ccess token. It doesn't matter if the continue uri leaks as it is usele= ss without an accompanying signature, i.e. any security benefit of having a= n access token is already provided by having a signature.
    The only benefits that I can see are:
    =C2=A0- If the AS wants to be fully stateless, then you can encode more= data in a token than in a uri
    =C2=A0- If the AS wants to = have a static endpoint for CRUD operations on the grant
    = =C2=A0- To allow the AS to identity a previous grant

    <= /div>
    If we dropped the access token for the continue endpoint a= nd rather mandated a dynamic uri this would make things conceptually easier= to understand, easier for the RC to implement, easier to debug and less ch= ance of errors when rotating tokens (i.e. race conditions could be quite li= kely if the AS always rotates the token)

    One-off g= rant with no continuation or ongoing management:
    RC se= nds signature and metadata, no `continue` response provided, therefore no g= rant management possible

    Grant with ongoing manage= ment
    RC sends signature and metadata, AS responds with= a continue uri that has these purposes:
    =C2=A0- can be us= ed by the RC to continue/update, read or revoke the grant

    As an RC the only perm= anent items I need to store are:
    =C2=A0- the continue uri = associated with the grant
    =C2=A0- any access tokens I rece= ive for the grant

    Dave
    On Tue, = 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Tor= sten,=C2=A0

    You're right on both accounts.=C2=A0
    - for the first remark, it fits quite nicely the init request=C2=A0 = / continuation pattern=C2=A0
    - for the second remark, it is a sor= t of handle for the continuation=C2=A0request, which will eventually lead t= o the issuance or refresh of standard access tokens=C2=A0

    Having a specific=C2=A0name is a possibility, I actually suggested = that too at some point.=C2=A0

    Fabien
    On Tue, = Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bri= stol, BS1 6FL
    t:=C2=A0+= 44 (0)117 280 5120

    <= div>
    Moneyhub Enterprise is a trading style of Moneyhub Financia= l Technology Limited which is authorised and regulated by the Financial Con= duct Authority ("FCA").=C2=A0Moneyhub Financial Technology is ent= ered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in England & Wales, compa= ny registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Fin= ancial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in = it other than by the addressee is unauthorised and unlawful. Whilst reasona= ble efforts are made to ensure that any attachments are virus-free, it is t= he recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorde= d for legitimate purposes relating to this company's business. Any opin= ions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techn= ology Limited or of any other group company.
    =

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bri= stol, BS1 6FL
    t:=C2=A0+= 44 (0)117 280 5120

    <= div>
    Moneyhub Enterprise is a trading style of Moneyhub Financia= l Technology Limited which is authorised and regulated by the Financial Con= duct Authority ("FCA").=C2=A0Moneyhub Financial Technology is ent= ered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in England & Wales, compa= ny registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Fin= ancial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in = it other than by the addressee is unauthorised and unlawful. Whilst reasona= ble efforts are made to ensure that any attachments are virus-free, it is t= he recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorde= d for legitimate purposes relating to this company's business. Any opin= ions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techn= ology Limited or of any other group company.
    =

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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



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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bri= stol, BS1 6FL
    t:=C2=A0+= 44 (0)117 280 5120

    <= div>
    Moneyhub Enterprise is a trading style of Moneyhub Financia= l Technology Limited which is authorised and regulated by the Financial Con= duct Authority ("FCA").=C2=A0Moneyhub Financial Technology is ent= ered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in England & Wales, compa= ny registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Fin= ancial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in = it other than by the addressee is unauthorised and unlawful. Whilst reasona= ble efforts are made to ensure that any attachments are virus-free, it is t= he recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorde= d for legitimate purposes relating to this company's business. Any opin= ions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techn= ology Limited or of any other group company.
    =

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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





    --
    <= div dir=3D"ltr">
    Dave Tonge
    CTO
    3D"Mon=
    Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120
    <= /div>

    Moneyh= ub Enterprise is a trading style of Moneyhub Financial Technology Limited w= hich is authorised and regulated by the Financial Conduct Authority ("= FCA").=C2=A0Moneyhub Financial Technology is entered on the Financial = Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= = . Moneyhub=C2=A0Financial T= echnology is registered in England & Wales, company registration number= =C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limi= ted 2019=C2=A0=C2=A9

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is conf= idential. Use of this email or of any information in it other than by the a= ddressee is unauthorised and unlawful. Whilst reasonable efforts are made t= o ensure that any attachments are virus-free, it is the recipient's sol= e responsibility to scan all attachments for viruses. All calls and emails = to and from this company may be monitored and recorded for legitimate purpo= ses relating to this company's business. Any opinions expressed in this= email (or in any attachments) are those of the author and do not necessari= ly represent the opinions of Moneyhub Financial Technology Limited or of an= y other group company.

    Moneyhub Enterprise is a = trading style of Moneyhub Financial Technology Limited which is authorised = and regulated by the Financial Conduct Authority ("FCA"). Moneyhu= b Financial Technology is entered on the Financial Services Register (FRN 8= 09360) at https://register.fc= a.org.uk/. Moneyhub Financial Technology is registered in Englan= d & Wales, company registration number 06909772. Moneyhub Financial Tec= hnology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Qua= y, 1 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is subject to co= pyright, and the information in it is confidential. Use of this email or of= any information in it other than by the addressee is unauthorised and unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5t= h Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2= =A0+44 (0)117 28= 0 5120

    =
    Moneyhub Enterprise is a trading style of Moneyhub F= inancial Technology Limited which is authorised and regulated by the Financ= ial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology= is entered on the Financial Services Register=C2=A0(FRN= =C2=A0809360) at https://register.fca.= org.uk/. Moneyhub=C2=A0Financial Technology is registe= red in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000001c17f905b692281f-- From nobody Wed Dec 16 03:07:24 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693013A0981 for ; Wed, 16 Dec 2020 03:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Am2FcAN0fxN for ; Wed, 16 Dec 2020 03:07:15 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9763A0978 for ; Wed, 16 Dec 2020 03:07:14 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id z5so23531967iob.11 for ; Wed, 16 Dec 2020 03:07: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=jnVdu9/W5T8iJ/+gJrpswgiwtq3rJtSmKSN3m7X5w9M=; b=ZTtHMxReevmO0YvRvU2uDxd8a0bNS6i6gGkNmUuWmM573AsuO/ngID1dWNpn2CUDOL erXNnUwef6KJNvy8NL6e61nXru6e1RcTgPif0yUIYxMBIPr4x6oIF++DfJzJFUb07tTo waNir68bx8GYtR5c5zJ5M1LGIB24TJ4rWSk5Kv4OxcNZSc7Gpnrc5mLj+e38ko6LuSWg KyhNrfDdFJoM8w9OiMg7qC0Wl2fIniH4nUWOT7lGuz3WZ9a/wGm5z2Ik1a8d+h5ZAHVw CSSUbfHgOInVn9eD4goNLDICMRFb8Dtvc1WCTOULVhGP/ICVVzSH/hhGILki8TffHJAy JIJw== 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=jnVdu9/W5T8iJ/+gJrpswgiwtq3rJtSmKSN3m7X5w9M=; b=rgzPnZAiRU4ijIhARx2OM66bcsHb5OdOrpt87S+UkZo9unelWchN0OxHe9LfWnW1QY M55s/onIp/Nb93JICgLwtDa5lu1IjOyHTOJd+muEVrCBFxTlpbUqw2+zubKz0OlSpLYB 7kINxOGI3AAz8sJvcKOtgFs1FoblFq4+GtC0dNtkCQiNBqB/DacWqMsff19b28Lwjve8 NgafpYZuU42n9hS0DrDa8e0mIzt7908NnWBpsfB5SSNAZlnPMb2OlnISPV59ui3u/l+P abBKspe+KyauBw1ifQoHplN/tNKgXPVK3mPtaSNikV3sGPvcBlphIw7UWEb86PkVXwFR 36Zg== X-Gm-Message-State: AOAM530HfD+NMtUFsr3MJca/xUHYxFnvsWAnMewZRBMB5rJrt5OX8HDy VynnE/E+UGiUWpK8gZTQwnNnDG44IC4k0+9aAKg= X-Google-Smtp-Source: ABdhPJymXrFRtIL12dYUCjS6vkTlf/hZKSlRi3rnvq0ATd2MQr1MBvWSYcJa2nTAyu2YWnkSnuAyODe7+sdC+XXfTqo= X-Received: by 2002:a6b:dd13:: with SMTP id f19mr41211463ioc.74.1608116833564; Wed, 16 Dec 2020 03:07:13 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> In-Reply-To: From: Fabien Imbault Date: Wed, 16 Dec 2020 12:07:01 +0100 Message-ID: To: Warren Parad Cc: Dave Tonge , Dick Hardt , Torsten Lodderstedt , txauth gnap , Justin Richer , Steve Moore Content-Type: multipart/alternative; boundary="0000000000009f3d2405b692e09d" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 16 Dec 2020 11:07:24 -0000 --0000000000009f3d2405b692e09d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I've created 2 separate issues : * Grant identifier https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146 * Rotation https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147 Cheers Fabien On Wed, Dec 16, 2020 at 11:15 AM Warren Parad wrote: > #4 is a prereq for this discussion though. If the token is the identifier > of the grant then it must be in the url to avoid the problem of arbitrary > url construction. Of course the uri would be *https://as/grants/{grantIde= ntifier} > *. And this is actually > independent of whether or not the token gets rotated. > > #3 The idea of a dynamic environment is important here, however the > argument doesn't justify having this being the same endpoint. Nothing sto= ps > us from having two endpoints, one that requests an access token separate > from the ones that manage the grant resource. > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge > wrote: > >> > Dave: which points changed your mind? >> >> 1. The issue with re-using client authentication across endpoints in the >> OAuth 2 world >> (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods= _supported, introspection_endpoint_auth_methods_supported...) >> >> 2. The clear articulation of the 3 different functions of the AS >> (including the idea of a self-hosted AS) >> >> 3. The aim to support a more dynamic environment where client >> authentication only happens in the first interaction between the RC and = the >> AS >> >> 4. The agreement that there should be further discussion on whether this >> access token should be rotated, and whether it should be an identifier o= f >> the grant. >> >> >> On Wed, 16 Dec 2020 at 00:02, Dick Hardt wrote: >> >>> Dave: which points changed your mind? >>> >>> On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge >>> wrote: >>> >>>> Thanks for the detailed response. >>>> >>>> I think you make the points well and I'm now in favour of the PR. >>>> However I do think that to keep the consistency that keeps being >>>> discussed, that the tokens shouldn't be rotated. >>>> >>>> I also think it would be good to have a discussion about "grant >>>> management" and identifiers for a grant. >>>> >>>> Dave >>>> >>>> On Tue, 15 Dec 2020 at 17:30, Justin Richer wrote: >>>> >>>>> On Dec 15, 2020, at 10:50 AM, Dave Tonge >>>>> wrote: >>>>> >>>>> >>>>> > The access token pattern has a lot of benefits, otherwise we >>>>> wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>>>> >>>>> *But what are the benefits in this particular use case?* The >>>>> continuation API is not like any other API - it is integral to the AS= . >>>>> There are quite a few extensions to OAuth that use client authenticat= ion >>>>> rather than access tokens. >>>>> >>>>> >>>>> Yes, and the propagation of that has lead to a mess in the OAuth >>>>> world. You=E2=80=99ve got re-definitions of client authentications at= all different >>>>> endpoints, they=E2=80=99re technically allowed to vary between endpoi= nts (though I >>>>> don=E2=80=99t know of it happening in practice, that feels like a dow= ngrade attack >>>>> waiting to happen to someone). Then there=E2=80=99s the fact that all= the newest >>>>> security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 = don=E2=80=99t rely on client >>>>> authentication at all to achieve security. All of these work without = the >>>>> client having credentials previously known to the AS, and we already = know >>>>> that GNAP is going to need to live in this more dynamic world. We nee= d to >>>>> think beyond what OAuth 2 has done in the past, and especially from o= ur >>>>> perceptions and assumptions of the models that drive OAuth 2=E2=80=99= s decisions, >>>>> lest we repeat its mistakes. >>>>> >>>>> Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2= =80=9D as a >>>>> point. In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the serv= er side, but in OAuth >>>>> 2 we split that into the RS concept. Even though in practice, a lot o= f RS=E2=80=99s >>>>> are still integrated to the AS in some fashion because it=E2=80=99s a= single >>>>> service, OAuth 2 is clear about what=E2=80=99s expected to be known b= y each >>>>> component. For the AS as currently defined in GNAP, I=E2=80=99m seein= g three >>>>> distinct functions. As per the Terminology discussion, we don=E2=80= =99t have >>>>> explicit names for these yet: >>>>> >>>>> - starting a request; this is an endpoint to kick things off; it >>>>> needs to be able to look up the rights asked for by the client (if it= knows >>>>> the client at all ahead of time) and make initial decisions about nee= ded >>>>> interaction and follow up >>>>> - continuing a request; this is an API that needs to know the contex= t >>>>> of the request itself, including which key it=E2=80=99s bound to; thi= s is separate >>>>> from any identity of the client and possibly the user, but an AS >>>>> implementation that has access to those elements can use them >>>>> - interacting with the user; this is front-facing and in OAuth today >>>>> is already deployed as a separate service in some places, we should e= mbrace >>>>> that at the very least (but doing so formally is a separate issue) >>>>> >>>>> Why separate these in this way? There is immense power in having a >>>>> single consistent way to start the process. The =E2=80=9Ccontinuation= API=E2=80=9D gives us >>>>> an HTTP-defined mechanism for managing a request over time, including= the >>>>> simple case of returning information from the front channel, but peop= le >>>>> have already raised the question of non-HTTP and self-hosted AS=E2=80= =99s, which >>>>> would probably want a different kind of continuation API to communica= te to >>>>> the AS. The same thing with separating out the interaction: there are= going >>>>> to be a lot of different ways to handle interaction out there, and no= t all >>>>> of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way that = a simple >>>>> implementation might do. We=E2=80=99re defining a protocol based stro= ngly on HTTP >>>>> and JSON, but we should structure it in such a way that it can be ext= ended >>>>> and translated elsewhere in a clear way. >>>>> >>>>> This all raises the question: if we can rely on a unique URL for >>>>> redirect-based interaction, why not here? The simple reason is that a= URL >>>>> is the :only: mechanism we have in the front channel for passing >>>>> information, and we need to warn implementors against including sensi= tive >>>>> information in it, and we need to protect it with additional items. W= e have >>>>> access to more than just URLs when we=E2=80=99re dealing with the con= tinuation API, >>>>> and we ought to make use of all of our tools in ways that are consist= ent >>>>> and make sense. >>>>> >>>>> From a previous email the advantages I see are: >>>>> - more data can be encoded in a token than in a uri (this seems more >>>>> of an edge case) >>>>> - it can be an identifier for the grant (I don't agree with this) >>>>> >>>>> >>>>> It allows the parts above to live separately, even if they don=E2=80= =99t HAVE >>>>> to. And it simplifies what we=E2=80=99re asking the client to do by m= aking it >>>>> consistent with other parts of the ecosystem. The AS offering an API >>>>> doesn=E2=80=99t :have: to be different, and OpenID Connect showed us,= with the >>>>> UserInfo Endpoint, that that=E2=80=99s very much the case in practice= . >>>>> >>>>> Having my client code do very similar things in slightly different >>>>> ways is not simpler. >>>>> >>>>> >>>>> Another question I have: *do we envisage granting access tokens to >>>>> the RC that will allow it to manage multiple grants*? >>>>> >>>>> >>>>> I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t= been brought up >>>>> as a use case to date. >>>>> >>>>> >>>>> I also think there will be confusion with the signing being used for >>>>> different things. Maybe it just needs to be called out in the spec th= at: >>>>> >>>>> Request 1: signature =3D client authentication >>>>> Request 2+: signature =3D proof of possession for access token >>>>> >>>>> >>>>> That=E2=80=99s more or less the intent of what=E2=80=99s in the speci= fication right >>>>> now, and why all the signature methods, which are used for both clien= t auth >>>>> and token possession, are all together in section 8 and not separated= by >>>>> use. (With the caveat: it=E2=80=99s only client authentication in th= e first >>>>> request if the AS knows about the client instance ahead of time, whic= h >>>>> isn=E2=80=99t always going to be true.) That all can likely be made c= learer, as is >>>>> always the case with spec text. But you can use the signature methods= with >>>>> and without access tokens, and it only gets used without in an initia= l call >>>>> where you don=E2=80=99t :have: an access token to present. >>>>> >>>>> Separating the different kinds of =E2=80=9Cclient authentication" out= in OAuth >>>>> is the source of some real confusion. Like right now, what happens if= you >>>>> try to combine a client assertion, signed request objects for PAR, an= d DPoP >>>>> proofs, all in a single request? All of these are optional and all of= them >>>>> =E2=80=9Cdo client authentication=E2=80=9D in some arguable fashion. = I=E2=80=99ve worked on several >>>>> systems and implemented these things, and their interplay is really >>>>> confusing to manage and can go sideways really fast. And that=E2=80= =99s just the >>>>> work for a single endpoint, this gets repeated for introspection, >>>>> revocation, CIBA, device, and on. >>>>> >>>>> At the end of the day I=E2=80=99m in favor of giving the client devel= opers a >>>>> very clear set of directions on what they need to do and how they nee= d to >>>>> access things, and treating the continuation as a token-bound API is,= to >>>>> me, the clearest pattern we can offer for this piece. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, 15 Dec 2020 at 15:33, Justin Richer wrote: >>>>> >>>>>> I agree with Fabien that the persistent identifier is a separate >>>>>> issue. The current spec re-uses the access token for this artifact, = but >>>>>> that=E2=80=99s potentially brittle and could be changed out for some= thing else. >>>>>> There=E2=80=99s an issue asking for expanding on the use cases for t= his >>>>>> functionality (which hasn=E2=80=99t been addressed by this PR): >>>>>> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >>>>>> A potentially-rotating URI would be just as brittle, and so having a >>>>>> single codified identifier for this artifact would be useful, but it= does >>>>>> assume some things about the nature of the AS. Every other use the c= lient >>>>>> has to manage the ongoing request over time doesn=E2=80=99t need an = explicit >>>>>> identifier. Just like with OAuth-protected APIs, the server can dete= rmine >>>>>> the context not just from the URI but from the rest of the request, >>>>>> including the access token itself. This is both more common and more >>>>>> powerful than a strict reading of REST designs. It also follows the = HATEOS >>>>>> principles as the entire HTTP request is taken into account, includi= ng the >>>>>> access token and signature portions. >>>>>> >>>>>> I=E2=80=99ll also point out that the rotation of these credentials i= s also >>>>>> filed as a separate issue that=E2=80=99s not being addressed right n= ow, so we can >>>>>> revisit that discussion separately: >>>>>> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >>>>>> As for the name, we could give it a different label. We have this >>>>>> same pattern of issuing a resource-specific access token alongside a= URL in >>>>>> the Dynamic Registration specification, both in OAuth ( >>>>>> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( >>>>>> https://openid.net/specs/openid-connect-registration-1_0.html#Regist= rationResponse). >>>>>> Here it=E2=80=99s called the =E2=80=9Cregistration access token=E2= =80=9D =E2=80=94 but what=E2=80=99s important >>>>>> there, as it is here, is that it=E2=80=99s not a different kind of a= rtifact that >>>>>> the client now has to figure out how to use, it=E2=80=99s an access = token plain and >>>>>> simple. In the OAuth world this is a bearer token, since that=E2=80= =99s what OAuth >>>>>> 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2= =80=99s what we=E2=80=99re >>>>>> looking to build on. This is also related to another future discussi= on >>>>>> about responses tying an access token to a specific API that=E2=80= =99s told to the >>>>>> client, as we could potentially re-use those components and concepts= here >>>>>> as well: >>>>>> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 >>>>>> >>>>>> And finally, no speculation on the complexity is needed: I >>>>>> implemented this pattern several months ago during the design team >>>>>> discussions when we were considering this pattern, and the code is a= ll >>>>>> online for people to see. >>>>>> >>>>>> https://github.com/bspk/oauth.xyz-java/ >>>>>> >>>>>> On the AS side, the most interesting code to this discussion is in >>>>>> the TransactionEndpoint class: >>>>>> >>>>>> >>>>>> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/= io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java >>>>>> >>>>>> Here, you=E2=80=99ll see that on initial request, the server looks u= p the >>>>>> client to see if it=E2=80=99s been registered, but after that, it ma= kes sure that >>>>>> the token and key are appropriate for the ongoing request. From the = client >>>>>> side it=E2=80=99s even simpler. The client=E2=80=99s got a small ser= vice function to manage >>>>>> the different signature methods that are implemented, and all of the= m can >>>>>> take in an optional access token: >>>>>> >>>>>> >>>>>> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/= io/bspk/oauth/xyz/http/SigningRestTemplateService.java >>>>>> >>>>>> The heavy lift is doing the actual signing, and you need that in >>>>>> order to start the process anyway. Managing the access token as an a= rtifact >>>>>> to use at the API is completely trivial since the client already nee= ds to >>>>>> manage its own state internally to do any of this. And note that all= of >>>>>> this is changed from how it was before: Previously, the XYZ Protocol= had >>>>>> used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that = the client would use to >>>>>> continue the request. However, this simple model was limiting, and t= he >>>>>> design team adopted XAuth=E2=80=99s model of continuation being an A= PI. In doing >>>>>> so, we made it like all of the other APIs the client is going to cal= l: in >>>>>> the initial state, it doesn=E2=80=99t have any kind of access rights= , it=E2=80=99s just >>>>>> calling. From that initial call forward, the AS just needs to know t= hat the >>>>>> token and key match what it expects. >>>>>> >>>>>> In summary, my views are: >>>>>> - The access token pattern has a lot of benefits, otherwise we >>>>>> wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>>>>> - Magic URIs have a lot of drawbacks which are well understood; >>>>>> while they can be mitigated, they can also be avoided >>>>>> - Continuation is an API, and treating it like the other kinds of >>>>>> API the client would call makes sense >>>>>> - Calling this by a special name, like =E2=80=9Cgrant access token= =E2=80=9D or >>>>>> =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should f= unction like any other >>>>>> access token >>>>>> - The heavy lift for clients is on protecting the message >>>>>> cryptographically, which they need to do anyway >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> On Dec 15, 2020, at 7:50 AM, Dave Tonge >>>>>> wrote: >>>>>> >>>>>> The persistent identifier is not a different issue, the current >>>>>> access token is used to reference an existing grant >>>>>> >>>>>> >>>>>> >>>>>> It may not be more difficult for a client to *use* an access token >>>>>> at the AS / RS. But there is definitely an overhead on the client to >>>>>> *manage* this separate access token. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> I think we always said the access token was different, and handled >>>>>>> as a bound token. >>>>>>> >>>>>>> But it doesn't mean it's more difficult for the client that already >>>>>>> needs to be able to handle tokens anyway (bearer or not, both cases= could >>>>>>> occur). It's mostly consolidating the logic. >>>>>>> >>>>>>> You're anticipating a lot of issues which have no specific reason t= o >>>>>>> occur, such as "can't be used with the token management APIs?". The >>>>>>> management API is part of the same general flow. >>>>>>> Anticipating issues with rotation is useful, but there are also man= y >>>>>>> ways it can be hard to manage through a stateful approach too. And >>>>>>> fundamentally, having everything in a common model (both for the in= ternals >>>>>>> of the AS and for the API calls) will help improve by a large margi= n what >>>>>>> is probably the weakest point in today's infrastructure. But it's e= arly to >>>>>>> be definitive as to the downstream impact either way. >>>>>>> >>>>>>> As for a persistent identifier instead of a continuation API, and >>>>>>> generally the end of your message, it's a totally unrelated issue t= o this >>>>>>> PR, so I suggest we don't discuss that here, but in a separate issu= e if >>>>>>> needed. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>>>>>> wrote: >>>>>>> >>>>>>>> So we've established that this is a different access token, that >>>>>>>> requires different handling at the client. So keeping it could cau= se more >>>>>>>> confusion? >>>>>>>> >>>>>>>> As an RC, I will have to store the continue `uri` as although it >>>>>>>> could be static it could also be dynamic. Why do I need to store a= n access >>>>>>>> token as well. It brings me no benefit as an RC, in fact it brings= more >>>>>>>> complexity. As I will now need to manage multiple types of tokens = with >>>>>>>> different lifecycles: >>>>>>>> >>>>>>>> *Continuation token* >>>>>>>> - can only be used at the continue endpoint (the name of which i= s >>>>>>>> confusing as I can use this endpoint to revoke a grant or get meta= data on >>>>>>>> the grant). >>>>>>>> - may be rotated each time it is used, or may not be >>>>>>>> - provided in the `continue` section of the response >>>>>>>> - must be sender-constrained >>>>>>>> - can't be used with the token management APIs? >>>>>>>> - can be used to identify the grant when making subsequent grants >>>>>>>> >>>>>>>> *Access token(s) to use at RS* >>>>>>>> - can only be used at the specified RS >>>>>>>> - may be sender constrained >>>>>>>> - when used at the RS, will not result in rotation >>>>>>>> >>>>>>>> From my perspective, most use-cases will require the RC to have a >>>>>>>> persistent identifier for the grant. Why not bring this into the p= rotocol >>>>>>>> and let the AS provide this persistent identifier (through the for= m of the >>>>>>>> continue uri). Using a rotating access token as a persistent ident= ifier >>>>>>>> doesn't seem like the right choice. >>>>>>>> >>>>>>>> I see no security benefit to having the continuation access token. >>>>>>>> It doesn't matter if the continue uri leaks as it is useless witho= ut an >>>>>>>> accompanying signature, i.e. any security benefit of having an acc= ess token >>>>>>>> is already provided by having a signature. >>>>>>>> >>>>>>>> The only benefits that I can see are: >>>>>>>> - If the AS wants to be fully stateless, then you can encode more >>>>>>>> data in a token than in a uri >>>>>>>> - If the AS wants to have a static endpoint for CRUD operations o= n >>>>>>>> the grant >>>>>>>> - To allow the AS to identity a previous grant >>>>>>>> >>>>>>>> If we dropped the access token for the continue endpoint and rathe= r >>>>>>>> mandated a dynamic uri this would make things conceptually easier = to >>>>>>>> understand, easier for the RC to implement, easier to debug and le= ss chance >>>>>>>> of errors when rotating tokens (i.e. race conditions could be quit= e likely >>>>>>>> if the AS always rotates the token) >>>>>>>> >>>>>>>> *One-off grant with no continuation or ongoing management:* >>>>>>>> RC sends signature and metadata, no `continue` response provided, >>>>>>>> therefore no grant management possible >>>>>>>> >>>>>>>> *Grant with ongoing management* >>>>>>>> RC sends signature and metadata, AS responds with a continue uri >>>>>>>> that has these purposes: >>>>>>>> - can be used by the RC to continue/update, read or revoke the >>>>>>>> grant >>>>>>>> - can be used by the RC when making a new grant to identify the >>>>>>>> previous grant >>>>>>>> >>>>>>>> As an RC the only permanent items I need to store are: >>>>>>>> - the continue uri associated with the grant >>>>>>>> - any access tokens I receive for the grant >>>>>>>> >>>>>>>> Dave >>>>>>>> >>>>>>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Torsten, >>>>>>>>> >>>>>>>>> You're right on both accounts. >>>>>>>>> - for the first remark, it fits quite nicely the init request / >>>>>>>>> continuation pattern >>>>>>>>> - for the second remark, it is a sort of handle for the >>>>>>>>> continuation request, which will eventually lead to the issuance = or refresh >>>>>>>>> of standard access tokens >>>>>>>>> >>>>>>>>> Having a specific name is a possibility, I actually suggested tha= t >>>>>>>>> too at some point. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>>>>>> torsten@lodderstedt.net> wrote: >>>>>>>>> >>>>>>>>>> Hi Fabien, >>>>>>>>>> >>>>>>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com>: >>>>>>>>>> > >>>>>>>>>> > Hi, >>>>>>>>>> > >>>>>>>>>> > On the contrary your feedback is most welcome. >>>>>>>>>> > >>>>>>>>>> > It doesn't accept any token, it needs the particular token as >>>>>>>>>> described in 3.1 and which is not a bearer token (that's what th= e "key" : >>>>>>>>>> true parameter is supposed to convey). >>>>>>>>>> > >>>>>>>>>> > Let us know if you need more clarifications. >>>>>>>>>> >>>>>>>>>> Thanks for the clarification. I think only accepting this kind o= f >>>>>>>>>> token at the continuation is a good idea otherwise the AS would = need to be >>>>>>>>>> able to parse and understand all sorts of access tokens. >>>>>>>>>> >>>>>>>>>> Conceptually, I like the idea to treat the continuation as >>>>>>>>>> another kind of resource. However, here are some observations I = want to >>>>>>>>>> share with you: >>>>>>>>>> - This resource is different as it will issue other access token= s >>>>>>>>>> (of this kind) to be used in subsequent continuation requests. T= his >>>>>>>>>> requires different handing on the client side. >>>>>>>>>> - This access token (if I understand correctly) is (or at least >>>>>>>>>> feels like) a handle for the underlying grant. So it is kind of = the super >>>>>>>>>> access token to obtain other access tokens. >>>>>>>>>> >>>>>>>>>> I would consider using a different term to refer to this special >>>>>>>>>> access token, grant token or grant handle for example, in order = to prevent >>>>>>>>>> confusion. >>>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> Torsten. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > Best >>>>>>>>>> > Fabien >>>>>>>>>> > >>>>>>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>>>>>> > Hi all, >>>>>>>>>> > >>>>>>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me que= stion >>>>>>>>>> seems naive. >>>>>>>>>> > >>>>>>>>>> > After having skimmed through the current draft and the PR, I= =E2=80=98m >>>>>>>>>> not sure whether the continuation requests accepts any access to= ken issued >>>>>>>>>> to the RC or the particular access token returned in the =E2=80= =9Econtinue=E2=80=9C element >>>>>>>>>> in section 3.1.. >>>>>>>>>> > >>>>>>>>>> > Can you please shed some light on this? >>>>>>>>>> > >>>>>>>>>> > kind regards, >>>>>>>>>> > Torsten. >>>>>>>>>> > >>>>>>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com>: >>>>>>>>>> >> >>>>>>>>>> >> =EF=BB=BF >>>>>>>>>> >> You're completely right. Allowing the dev to be lazy is a ver= y >>>>>>>>>> good thing in general, because it's what we know will work :-) >>>>>>>>>> >> >>>>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore >>>>>>>>>> a =C3=A9crit : >>>>>>>>>> >> Hi Fabien, >>>>>>>>>> >> >>>>>>>>>> >> For #3) Even after I typed out the hypothetical attack, that >>>>>>>>>> was sort of in the back of my mind, it isn't a huge risk there. = So I >>>>>>>>>> actually agree with Dick there. Something doesn't sit right with= me for the >>>>>>>>>> unique URL solution, so I don't like it and came up with a hypot= hetical >>>>>>>>>> that seems like it could be a down side. >>>>>>>>>> >> >>>>>>>>>> >> I still think the access token model with the signed request >>>>>>>>>> is the way I'd like to go, because again, it's a mechanism I'd b= e >>>>>>>>>> implementing anyway to talk to any 'normal' resource. The fact i= s there is >>>>>>>>>> _something_ representing context that has to pass back and forth= here, >>>>>>>>>> whether that is an access token (which I feel like is more flexi= ble for >>>>>>>>>> extensions etc), a unique url, or even a cookie sent in the cook= ie header. >>>>>>>>>> So just to re-iterate, I'm a +1 on this pull request, speaking a= s a lazy >>>>>>>>>> developer ;) >>>>>>>>>> >> -steve >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >> Again speaking in my own name here. >>>>>>>>>> >> >>>>>>>>>> >> Dick, we know you'd prefer to have a different design, but >>>>>>>>>> this PR shouldn't be about that. >>>>>>>>>> >> >>>>>>>>>> >> Back on your 3 items : >>>>>>>>>> >> >>>>>>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>>>>>> decided that wouldn't be how that would work. We have a client i= nstance >>>>>>>>>> that allows a more generic and flexible pattern (which BTW also = allows what >>>>>>>>>> you want) >>>>>>>>>> >> >>>>>>>>>> >> 2) instead of blame arguments of who's less >>>>>>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversa= tions, I >>>>>>>>>> suggest we speak in less abstract terms and ask ourselves what t= hat means >>>>>>>>>> in practice for devs. Stephen and several others (myself include= d) have >>>>>>>>>> expressed that it wouldn't be harder to implement, it would even= simplify >>>>>>>>>> things quite a lot. If you disagree please send us a code sample= to really >>>>>>>>>> show that point by example, because that's really not obvious. >>>>>>>>>> >> >>>>>>>>>> >> 3) "If someone has the client credentials, they can >>>>>>>>>> impersonate the client, and all bets are off." Are you seriously= making >>>>>>>>>> this argument? Because if you have a better proposal than using >>>>>>>>>> cryptographic keys, I'm all hears. You make it look like there's= a problem, >>>>>>>>>> while in reality we're only relying on the basic assumption of a= ll modern >>>>>>>>>> digital communications. >>>>>>>>>> >> >>>>>>>>>> >> And more importantly you never responded to the issues of how >>>>>>>>>> to avoid the security pitfalls of what you proposed. >>>>>>>>>> >> >>>>>>>>>> >> Fabien >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt >>>>>>>>>> a =C3=A9crit : >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore < >>>>>>>>>> srmoore@gmail.com> wrote: >>>>>>>>>> >> But from the spec: >>>>>>>>>> >> " >>>>>>>>>> >> When sending a non-continuation request to the AS, the RC MUS= T >>>>>>>>>> identify itself by including the client field of the request... >>>>>>>>>> >> ... >>>>>>>>>> >> key (object / string) : The public key of the RC to be used i= n >>>>>>>>>> this request as described in {{request-key}}. This field is REQU= IRED. >>>>>>>>>> >> ... >>>>>>>>>> >> " >>>>>>>>>> >> So on the initial request, the key will be there. >>>>>>>>>> >> >>>>>>>>>> >> The client field can be an object or a string. If the client >>>>>>>>>> is pre-registered, then a string could be provided instead of an= object. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> If you don't have the access token, then how do you >>>>>>>>>> differentiate between two requests from the same web application= by two >>>>>>>>>> different users? Is the web application supposed to have differe= nt >>>>>>>>>> credentials for every request? >>>>>>>>>> >> >>>>>>>>>> >> The AS returns a URI for manipulating the request. I would >>>>>>>>>> change the spec so that each request would have a unique URI. Th= is is the >>>>>>>>>> usually RESTful pattern that the resource (the grant request) ha= s an URI. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> So in this case, the easy way out is to pass the access token >>>>>>>>>> to the client, who then, as i stated before, treats the continue= request as >>>>>>>>>> a RS call (albeit a specialized version of the RS where the RS i= s the AS) >>>>>>>>>> OR to use the unique URL, >>>>>>>>>> >> but that seems open to a brute force attack by a malicious RC= . >>>>>>>>>> (What would be the point of that attack, I don't know, I guess i= f someone >>>>>>>>>> had the client credentials but not any subjects/resources they c= ould try to >>>>>>>>>> intercept the grant via continue... I just don't feel right lock= ing things >>>>>>>>>> down to unique URLs that way.) >>>>>>>>>> >> >>>>>>>>>> >> If someone has the client credentials, they can impersonate >>>>>>>>>> the client, and all bets are off. >>>>>>>>>> >> >>>>>>>>>> >> LOTS of RS servers return a resource specific URL -- my >>>>>>>>>> proposal is no different. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> -steve >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt < >>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>> >> Hi Stephen >>>>>>>>>> >> >>>>>>>>>> >> The client is signing the first request. The key *might* be i= n >>>>>>>>>> the body. The client is signing all the subsequent requests as w= ell. The >>>>>>>>>> "access token" is not needed by the client to prove it is author= ized as the >>>>>>>>>> client is proving it is the same client again. >>>>>>>>>> >> >>>>>>>>>> >> In other words, I don't see the need for an access token, so >>>>>>>>>> it does not need to be put in a URL or an auth header. >>>>>>>>>> >> >>>>>>>>>> >> If a developer really, really wants to hand context back to >>>>>>>>>> the client for subsequent calls, they can put it in the URL or s= ome other >>>>>>>>>> method. Putting it in the HTTP Authorization header is confusing= because it >>>>>>>>>> is NOT an access token -- it is the context of the request. >>>>>>>>>> >> >>>>>>>>>> >> =E1=90=A7 >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore < >>>>>>>>>> srmoore@gmail.com> wrote: >>>>>>>>>> >> Even though I've only been lightly following things, I feel >>>>>>>>>> the need to voice my preference as a developer since I will prob= ably >>>>>>>>>> someday have to either write a RC or RS... >>>>>>>>>> >> >>>>>>>>>> >> The way I see it is the RC makes the initial request to the A= S >>>>>>>>>> as part of this request, it provides it's key in the body... (So= no use of >>>>>>>>>> the Authorization header) >>>>>>>>>> >> At this point that request, represented by the continue URL + >>>>>>>>>> "Access Token", from my lazy developer standpoint, is a Resource= Endpoint >>>>>>>>>> and Access Token, and the AS is acting as a specialized RS in th= is case. >>>>>>>>>> >> So my client posts to whatever URL with the 'access token' in >>>>>>>>>> the authorization header, just like acting on any other resource= I have a >>>>>>>>>> token for. YES, I get a new token value to use every call, and t= here is a >>>>>>>>>> decision point of "Do I have another continue, or do I have a re= al token >>>>>>>>>> for the resource..." But the mechanism is the same to me in the = client. >>>>>>>>>> >> Personally I like that, because if I have an access_token, I >>>>>>>>>> already think "Put it in the auth header." >>>>>>>>>> >> >>>>>>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>>>>>> >> -steve >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt < >>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>> >> inline ... >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >> Others had already responded to this previous thread, but I >>>>>>>>>> wanted to add a couple points to clarify some things. >>>>>>>>>> >> >>>>>>>>>> >>> 3) What the client has to do with the "access token" is not >>>>>>>>>> the same as access tokens for an RS. The client gets a new "acce= ss token" >>>>>>>>>> for each grant request, and for each API call to the AS, and the= client >>>>>>>>>> learns it can not make any more API calls for that specific requ= est when it >>>>>>>>>> does not get an "access token" back. This is a completely differ= ent design >>>>>>>>>> pattern than calling an RS API with an access token, and is a ne= w design >>>>>>>>>> pattern for calling APIs. This adds complexity to the client tha= t it would >>>>>>>>>> not normally have, and I don't think GNAP is the right place to = start a new >>>>>>>>>> design pattern. >>>>>>>>>> >>> >>>>>>>>>> >> >>>>>>>>>> >> I=E2=80=99m not sure what you mean by these being different = =E2=80=94 the >>>>>>>>>> whole point of the design is that the client would be doing the = same thing >>>>>>>>>> with the access token at the AS that it does with the RS by re-u= sing the >>>>>>>>>> access token structure. Can you please describe what the differe= nces are, >>>>>>>>>> apart from the rotation? Presentation of the token and signing o= f the >>>>>>>>>> message are identical. >>>>>>>>>> >> >>>>>>>>>> >> The client is getting the "access token" from its API. It is >>>>>>>>>> not using an "access_token" in other API calls to the AS. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>>>>>> continuation responses is a separate issue to be discussed: >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>>>>> >> >>>>>>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right= place to >>>>>>>>>> have new designs =E2=80=94 not that this is one. >>>>>>>>>> >> >>>>>>>>>> >> You are proposing a new way for an API to provide context for >>>>>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >>> 4) Clients that only want claims from the AS and no access >>>>>>>>>> tokens will be required to support an API calling mechanism they= would not >>>>>>>>>> have to support otherwise. >>>>>>>>>> >> >>>>>>>>>> >> Correct, but the delta between the calls a client would make >>>>>>>>>> with and without an access token is vanishingly small. The clien= t has to >>>>>>>>>> sign the initial request in some fashion, and it will sign the c= ontinuation >>>>>>>>>> request in the same exact fashion, but now include an access tok= en in that >>>>>>>>>> request. >>>>>>>>>> >> >>>>>>>>>> >> Per my other point, there is no value to me in my >>>>>>>>>> implementations of passing context back and forth between the cl= ient and AS >>>>>>>>>> -- so it is extra work providing no value. >>>>>>>>>> >> >>>>>>>>>> >> Also, any client authentication mechanism that wants to use >>>>>>>>>> the HTTP Authentication header is precluded from using it. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> Clients making a request to an AS and not getting an access >>>>>>>>>> token is a new design pattern. I think it has value and should b= e included, >>>>>>>>>> but OAuth today shows us the immense value of getting access tok= ens for >>>>>>>>>> calling APIs, and so we shouldn=E2=80=99t optimize away from tha= t pattern. >>>>>>>>>> >> >>>>>>>>>> >>> >>>>>>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>>>>>> mechanism for a client to delete the request, as the client is n= ot allowed >>>>>>>>>> to make a call without an "access token". >>>>>>>>>> >> >>>>>>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue= =E2=80=9D field >>>>>>>>>> then the client can=E2=80=99t delete the request =E2=80=94 and y= es, that=E2=80=99s intentional. The >>>>>>>>>> AS is telling this client instance that it can=E2=80=99t do anyt= hing else with this >>>>>>>>>> ongoing request. If the AS wants to allow the client to manage i= t, it will >>>>>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80= =9D field. >>>>>>>>>> >> >>>>>>>>>> >> There is nuance in that intention. A related concern is that >>>>>>>>>> deleting a request does not seem like it is a "continue" operati= on. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >>> >>>>>>>>>> >>> 6) There is no standard identifier for the request. Debuggin= g >>>>>>>>>> and auditing are hampered by the client and AS having no standar= d way to >>>>>>>>>> identifying a request. While one AS may provide a unique URL for= each grant >>>>>>>>>> request, another AS may use a persistent "access token" to ident= ify the >>>>>>>>>> grant request, and other ASs may issue a new "access token" on e= ach API >>>>>>>>>> call, providing no persistent identifier for the request. >>>>>>>>>> >> >>>>>>>>>> >> Debugging and auditing this kind of thing are functions of th= e >>>>>>>>>> AS. How is interoperability harmed by different ASs having diffe= rent >>>>>>>>>> methods to identify their internal data elements? The client doe= sn=E2=80=99t need >>>>>>>>>> any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps >>>>>>>>>> for continuing the negotiation. >>>>>>>>>> >> >>>>>>>>>> >> Debugging between the client and the AS was what I was >>>>>>>>>> referring to. How does a client developer identify the request w= hen >>>>>>>>>> communicating to the AS developer. Seems complicated. >>>>>>>>>> >> >>>>>>>>>> >> =E1=90=A7 >>>>>>>>>> >> -- >>>>>>>>>> >> TXAuth mailing list >>>>>>>>>> >> TXAuth@ietf.org >>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >> =E1=90=A7 >>>>>>>>>> >> -- >>>>>>>>>> >> TXAuth mailing list >>>>>>>>>> >> TXAuth@ietf.org >>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >> -- >>>>>>>>>> >> TXAuth mailing list >>>>>>>>>> >> TXAuth@ietf.org >>>>>>>>>> >> >>>>>>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/list= info/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dave Tonge >>>>>>>> CTO >>>>>>>> [image: Moneyhub Enterprise] >>>>>>>> >>>>>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>>>>> BS1 6FL >>>>>>>> >>>>>>>> t: +44 (0)117 280 5120 >>>>>>>> >>>>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>>>> Technology Limited which is authorised and regulated by the Financ= ial >>>>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entere= d on the >>>>>>>> Financial Services Register (FRN 809360) at *https://register.fca.= org.uk/ >>>>>>>> *. Moneyhub Financial Technology is >>>>>>>> registered in England & Wales, company registration number >>>>>>>> 06909772 . >>>>>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>>>>> >>>>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>>>> copyright, and the information in it is confidential. Use of this = email or >>>>>>>> of any information in it other than by the addressee is unauthoris= ed and >>>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any at= tachments >>>>>>>> are virus-free, it is the recipient's sole responsibility to scan = all >>>>>>>> attachments for viruses. All calls and emails to and from this com= pany may >>>>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>>>> company's business. Any opinions expressed in this email (or in an= y >>>>>>>> attachments) are those of the author and do not necessarily repres= ent the >>>>>>>> opinions of Moneyhub Financial Technology Limited or of any other = group >>>>>>>> company. >>>>>>>> >>>>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>>>> Technology Limited which is authorised and regulated by the Financ= ial >>>>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entere= d on the >>>>>>>> Financial Services Register (FRN 809360) at >>>>>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>>>>> registered in England & Wales, company registration number 0690977= 2. >>>>>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterpr= ise, Regus >>>>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>>>> copyright, and the information in it is confidential. Use of this = email or >>>>>>>> of any information in it other than by the addressee is unauthoris= ed and >>>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any at= tachments >>>>>>>> are virus-free, it is the recipient's sole responsibility to scan = all >>>>>>>> attachments for viruses. All calls and emails to and from this com= pany may >>>>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>>>> company's business. Any opinions expressed in this email (or in an= y >>>>>>>> attachments) are those of the author and do not necessarily repres= ent the >>>>>>>> opinions of Moneyhub Financial Technology Limited or of any other = group >>>>>>>> company. >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Dave Tonge >>>>>> CTO >>>>>> [image: Moneyhub Enterprise] >>>>>> >>>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>>> BS1 6FL >>>>>> >>>>>> t: +44 (0)117 280 5120 >>>>>> >>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at *https://register.fca.or= g.uk/ >>>>>> *. Moneyhub Financial Technology is >>>>>> registered in England & Wales, company registration number 06909772 >>>>>> . >>>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at >>>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>>> registered in England & Wales, company registration number 06909772. >>>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterpris= e, Regus >>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>>> >>>>>> . >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Tonge >>>>> CTO >>>>> [image: Moneyhub Enterprise] >>>>> >>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>> BS1 6FL >>>>> >>>>> t: +44 (0)117 280 5120 >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at *https://register.fca.org= .uk/ >>>>> *. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772 = . >>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at >>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772. >>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise= , Regus >>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>> >>>>> . >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Dave Tonge >>>> CTO >>>> [image: Moneyhub Enterprise] >>>> >>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>>> 6FL >>>> >>>> t: +44 (0)117 280 5120 >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at *https://register.fca.org.= uk/ >>>> *. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772 . >>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>> >>>> . >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6= FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000009f3d2405b692e09d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    I've created 2 separate i= ssues :=C2=A0

    C= heers
    Fabien

    On Wed, Dec 16, 2020 at 11:15 AM Warren Parad= <wparad@rhosys.ch> wrote:
    #= 4 is a prereq for this discussion though. If the token is the identifier of= the grant then it must be in the url to avoid the problem of arbitrary url= construction. Of course the uri would be https://as/grants/{grantIdentifier}= . And this is actually independent of whether or not the token gets= rotated.

    #3 The idea of a dynamic environment is i= mportant here, however the argument doesn't justify having this being t= he same endpoint. Nothing stops us from having two endpoints, one that requ= ests an access token separate from the ones that manage the grant resource.=

    Warren Parad=

    Founde= r, CTO

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


    On Wed, Dec 16, 2020= at 10:09 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    >=C2= =A0Dave: which point= s changed your mind?

    1. The issue w= ith re-using client authentication across endpoints in the OAuth 2 world (t= oken_endpoint_auth_methods_supported,=C2=A0revocation_endpoint_auth_methods= _supported,=C2=A0introspection_endpoint_auth_methods_supported...)
    2. The clear articulat= ion of the 3 different functions of the AS (including the idea of a self-ho= sted AS)

    3.= The aim to support a more dynamic environment where client authentication = only happens in the first interaction between the RC and the AS

    4. The agreement that there should be further d= iscussion on whether this access token should be rotated, and whether it sh= ould be an identifier of the grant.


    On Wed, 16 Dec 2020 at 0= 0:02, Dick Hardt <dick.hardt@gmail.com> wrote:
    Dave: which points changed your m= ind?

    On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <dave.tonge@moneyhub.com> w= rote:
    Thanks for the detailed response.
    I think you make the points well and I'm now in favo= ur of the PR.
    However I do think that to keep the consiste= ncy that keeps being discussed, that the tokens shouldn't be rotated.= =C2=A0

    I also think it would be good= to have a discussion about "grant management" and identifiers fo= r a grant.

    On Tue, 15 Dec 2020 at 17:30, Justin Richer <jricher@mit.edu> wrote:
    On Dec 15, 2020, = at 10:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    >=C2=A0The access token pattern has a lot = of benefits, otherwise we wouldn=E2=80=99t have an entire OAuth ecosystem b= ased on it

    But what ar= e the benefits=C2=A0in this particular use case? The continuation API i= s not like any other API - it is integral to the AS. There are quite a few = extensions to OAuth that use client authentication rather than access token= s.

    Yes, and the propagati= on of that has lead to a mess in the OAuth world. You=E2=80=99ve got re-def= initions of client authentications at all different endpoints, they=E2=80= =99re technically allowed to vary between endpoints (though I don=E2=80=99t= know of it happening in practice, that feels like a downgrade attack waiti= ng to happen to someone). Then there=E2=80=99s the fact that all the newest= security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 don= =E2=80=99t rely on client authentication at all to achieve security. All of= these work without the client having credentials previously known to the A= S, and we already know that GNAP is going to need to live in this more dyna= mic world. We need to think beyond what OAuth 2 has done in the past, and e= specially from our perceptions and assumptions of the models that drive OAu= th 2=E2=80=99s decisions, lest we repeat its mistakes.=C2=A0

    =
    Also, I want to challenge this idea of =E2=80=9Cintegral to the = AS=E2=80=9D as a point. In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D = to the server side, but in OAuth 2 we split that into the RS concept. Even = though in practice, a lot of RS=E2=80=99s are still integrated to the AS in= some fashion because it=E2=80=99s a single service, OAuth 2 is clear about= what=E2=80=99s expected to be known by each component. For the AS as curre= ntly defined in GNAP, I=E2=80=99m seeing three distinct functions. As per t= he Terminology discussion, we don=E2=80=99t have explicit names for these y= et:

    =C2=A0- starting a request; this is an endpoin= t to kick things off; it needs to be able to look up the rights asked for b= y the client (if it knows the client at all ahead of time) and make initial= decisions about needed interaction and follow up
    =C2=A0- continuing a= request; this is an API that needs to know the context of the request itse= lf, including which key it=E2=80=99s bound to; this is separate from any id= entity of the client and possibly the user, but an AS implementation that h= as access to those elements can use them
    =C2=A0- interacting with= the user; this is front-facing and in OAuth today is already deployed as a= separate service in some places, we should embrace that at the very least = (but doing so formally is a separate issue)

    Why se= parate these in this way? There is immense power in having a single consist= ent way to start the process. The =E2=80=9Ccontinuation API=E2=80=9D gives = us an HTTP-defined mechanism for managing a request over time, including th= e simple case of returning information from the front channel, but people h= ave already raised the question of non-HTTP and self-hosted AS=E2=80=99s, w= hich would probably want a different kind of continuation API to communicat= e to the AS. The same thing with separating out the interaction: there are = going to be a lot of different ways to handle interaction out there, and no= t all of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way that = a simple implementation might do. We=E2=80=99re defining a protocol based s= trongly on HTTP and JSON, but we should structure it in such a way that it = can be extended and translated elsewhere in a clear way.

    This a= ll raises the question: if we can rely on a unique URL for redirect-based i= nteraction, why not here? The simple reason is that a URL is the :only: mec= hanism we have in the front channel for passing information, and we need to= warn implementors against including sensitive information in it, and we ne= ed to protect it with additional items. We have access to more than just UR= Ls when we=E2=80=99re dealing with the continuation API, and we ought to ma= ke use of all of our tools in ways that are consistent and make sense.

    From a previous email the advantages I see are:
    =C2=A0- more data can be encoded in a token t= han in a uri (this seems more of an edge case)
    =C2=A0- it can be an identifier for the grant (I don't agree with= this)

    It allows the part= s above to live separately, even if they don=E2=80=99t HAVE to. And it simp= lifies what we=E2=80=99re asking the client to do by making it consistent w= ith other parts of the ecosystem. The AS offering an API doesn=E2=80=99t :h= ave: to be different, and OpenID Connect showed us, with the UserInfo Endpo= int, that that=E2=80=99s very much the case in practice.=C2=A0
    Having my client code do very similar things in slightly diffe= rent ways is not simpler.


    Another question I have: do we envisage granting access tokens to the = RC that will allow it to manage multiple grants?=C2=A0=C2=A0

    I don=E2=80=99t see that happening,= personally, and it hasn=E2=80=99t been brought up as a use case to date.= =C2=A0


    I also think ther= e will be confusion with the signing being used for different things. Maybe= it just needs to be called out in the spec that:

    Request 1: signature = =3D client authentication
    Request 2+: sig= nature =3D proof of possession for access token


    That=E2=80=99= s more or less the intent of what=E2=80=99s in the specification right now,= and why all the signature methods, which are used for both client auth and= token possession, are all together in section 8 and not separated by use. = =C2=A0(With the caveat: it=E2=80=99s only client authentication in the firs= t request if the AS knows about the client instance ahead of time, which is= n=E2=80=99t always going to be true.) That all can likely be made clearer, = as is always the case with spec text. But you can use the signature methods= with and without access tokens, and it only gets used without in an initia= l call where you don=E2=80=99t :have: an access token to present.

    Separating the different kinds of =E2=80=9Cclient authentic= ation" out in OAuth is the source of some real confusion. Like right n= ow, what happens if you try to combine a client assertion, signed request o= bjects for PAR, and DPoP proofs, all in a single request? All of these are = optional and all of them =E2=80=9Cdo client authentication=E2=80=9D in some= arguable fashion. I=E2=80=99ve worked on several systems and implemented t= hese things, and their interplay is really confusing to manage and can go s= ideways really fast. And that=E2=80=99s just the work for a single endpoint= , this gets repeated for introspection, revocation, CIBA, device, and on.

    At the end of the day I=E2=80=99m in favor of givin= g the client developers a very clear set of directions on what they need to= do and how they need to access things, and treating the continuation as a = token-bound API is, to me, the clearest pattern we can offer for this piece= .

    =C2=A0=E2=80=94 Justin




    <= div class=3D"gmail_default">




    On Tue, 15 Dec 2020 at 15= :33, Justin Richer <jricher@mit.edu> wrote:
    I agree with Fabien that the persistent identifier is = a separate issue. The current spec re-uses the access token for this artifa= ct, but that=E2=80=99s potentially brittle and could be changed out for som= ething else. There=E2=80=99s an issue asking for expanding on the use cases= for this functionality (which hasn=E2=80=99t been addressed by this PR):

    A potentially-rotating URI would= be just as brittle, and so having a single codified identifier for this ar= tifact would be useful, but it does assume some things about the nature of = the AS. Every other use the client has to manage the ongoing request over t= ime doesn=E2=80=99t need an explicit identifier. Just like with OAuth-prote= cted APIs, the server can determine the context not just from the URI but f= rom the rest of the request, including the access token itself. This is bot= h more common and more powerful than a strict reading of REST designs. It a= lso follows the HATEOS principles as the entire HTTP request is taken into = account, including the access token and signature portions.=C2=A0

    I=E2=80=99ll also point out that the rotation of these cred= entials is also filed as a separate issue that=E2=80=99s not being addresse= d right now, so we can revisit that discussion separately:

    https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/87

    As for the name, we could give it a diffe= rent label. We have this same pattern of issuing a resource-specific access= token alongside a URL in the Dynamic Registration specification, both in O= Auth (https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connec= t (https://openid.net/specs/openid-co= nnect-registration-1_0.html#RegistrationResponse). Here it=E2=80=99s ca= lled the =E2=80=9Cregistration access token=E2=80=9D =E2=80=94 but what=E2= =80=99s important there, as it is here, is that it=E2=80=99s not a differen= t kind of artifact that the client now has to figure out how to use, it=E2= =80=99s an access token plain and simple. In the OAuth world this is a bear= er token, since that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2= =80=99ll be a bound token, as that=E2=80=99s what we=E2=80=99re looking to = build on. This is also related to another future discussion about responses= tying an access token to a specific API that=E2=80=99s told to the client,= as we could potentially re-use those components and concepts here as well:=


    And finally, no sp= eculation on the complexity is needed: I implemented this pattern several m= onths ago during the design team discussions when we were considering this = pattern, and the code is all online for people to see.=C2=A0

    =

    = On the AS side, the most interesting code to this discussion is in the Tran= sactionEndpoint class:


    Here, = you=E2=80=99ll see that on initial request, the server looks up the client = to see if it=E2=80=99s been registered, but after that, it makes sure that = the token and key are appropriate for the ongoing request. From the client = side it=E2=80=99s even simpler. The client=E2=80=99s got a small service fu= nction to manage the different signature methods that are implemented, and = all of them can take in an optional access token:=C2=A0


    =
    The heavy lift is doing the actual signing, and you need that in= order to start the process anyway. Managing the access token as an artifac= t to use at the API is completely trivial since the client already needs to= manage its own state internally to do any of this. And note that all of th= is is changed from how it was before: Previously, the XYZ Protocol had used= a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the client = would use to continue the request. However, this simple model was limiting,= and the design team adopted XAuth=E2=80=99s model of continuation being an= API. In doing so, we made it like all of the other APIs the client is goin= g to call: in the initial state, it doesn=E2=80=99t have any kind of access= rights, it=E2=80=99s just calling. From that initial call forward, the AS = just needs to know that the token and key match what it expects.=C2=A0

    In summary, my views are:
    =C2=A0- The access= token pattern has a lot of benefits, otherwise we wouldn=E2=80=99t have an= entire OAuth ecosystem based on it
    =C2=A0- Magic URIs have a lot= of drawbacks which are well understood; while they can be mitigated, they = can also be avoided
    =C2=A0- Continuation is an API, and treating = it like the other kinds of API the client would call makes sense
    = =C2=A0- Calling this by a special name, like =E2=80=9Cgrant access token=E2= =80=9D or =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it shoul= d function like any other access token
    =C2=A0- The heavy lift for= clients is on protecting the message cryptographically, which they need to= do anyway

    =C2=A0=E2=80=94 Justin


    On Dec 15, 2020, at 7:50 AM, Dave Ton= ge <dave.to= nge@moneyhub.com> wrote:

    reference an existing grant=C2=A0
    =

    It may not be more difficult for a client= to use an= access token at the AS / RS. But there=C2=A0is definitely an overhead on t= he client to m= anage=C2=A0this separate access token.=C2=A0



    On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <fabien.imbault@g= mail.com> wrote:
    I think we always said the access token was differ= ent, and handled as a bound token.

    But it doesn't me= an it's more difficult for the client that already needs to be able to = handle tokens anyway (bearer or not, both cases could occur). It's most= ly consolidating the logic.

    You're antici= pating a lot of issues which have no specific reason to occur, such as &quo= t;can't= be used with the token management APIs?". The management API is part = of the same general flow.
    Anticipating issues with rotation is useful= , but there are also many ways it can be hard to manage through a stateful = approach too. And fundamentally, having everything in a common model (both = for the internals of the AS and for the API calls) will help improve by a l= arge margin what is probably the weakest point in today's infrastructur= e. But it's early to be definitive as to the downstream impact either w= ay.=C2=A0 =C2=A0

    As for a persistent identifier instea= d of a continuation API, and generally the end of your message, it's a = totally unrelated issue to this PR, so I suggest we don't discuss that = here, but in a separate issue if needed.

    <= div>Fabien

    On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established that this is a differen= t access token, that requires different handling at the client. So keeping = it could cause more confusion?

    As an= RC, I will have to store the continue `uri` as although it could be static= it could also be dynamic. Why do I need to store an access token as well.= =C2=A0It brings me no benefit as an RC, in fact it brings more complexity. = As I will now need to manage multiple types of tokens with different lifecy= cles:

    Continuation token=C2=A0
    =C2=A0- may be rotated each time it is used, or= may not be
    =C2=A0- provided in the `continue` section of = the response
    =C2=A0- must be sender-constrained
    =C2=A0- can't be used with the token management APIs?
    =C2=A0- can be used to identify the grant when making subsequent gra= nts

    Access token(s) to use at RS
    =C2=A0= =C2=A0- can only be used at the specified RS
    =C2=A0 - may = be sender constrained
    =C2=A0 - when used at the RS, will n= ot result in rotation

    From my perspe= ctive, most use-cases will require the RC to have a persistent identifier f= or the grant. Why not bring this into the protocol and let the AS provide t= his persistent identifier (through the form of the continue uri). Using a r= otating access token as a persistent identifier doesn't seem like the r= ight choice.=C2=A0

    I see no security= benefit to having the continuation access token. It doesn't matter if = the continue uri leaks as it is useless without an accompanying signature, = i.e. any security benefit of having an access token is already provided by = having a signature.

    The only benefit= s that I can see are:
    =C2=A0- If the AS wants to be fully = stateless, then you can encode more data in a token than in a uri
    =C2=A0- If the AS wants to have a static endpoint for CRUD operatio= ns on the grant
    =C2=A0- To allow the AS to identity a prev= ious grant

    If we dropped the access = token for the continue endpoint and rather mandated a dynamic uri this woul= d make things conceptually easier to understand, easier for the RC to imple= ment, easier to debug and less chance of errors when rotating tokens (i.e. = race conditions could be quite likely if the AS always rotates the token)

    One-off grant with no continuation or ongoing manag= ement:
    RC sends signature and metadata, no `continue` = response provided, therefore no grant management possible
    Grant with ongoing management
    RC sends signa= ture and metadata, AS responds with a continue uri that has these purposes:=
    =C2=A0- can be used by the RC to continue/update, read or= revoke the grant
    =C2=A0- can be used by the RC when makin= g a new grant to identify the previous grant

    As an RC the only permanent items I need to store are:
    = =C2=A0- any access tokens I receive for the grant

    Dave

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@= gmail.com> wrote:
    Hi Torsten,=C2=A0

    You're= right on both accounts.=C2=A0
    - for the first remark, it fits qu= ite nicely the init request=C2=A0 / continuation pattern=C2=A0
    - = for the second remark, it is a sort of handle for the continuation=C2=A0req= uest, which will eventually lead to the issuance or refresh of standard acc= ess tokens=C2=A0

    Having a specific=C2=A0name is a = possibility, I actually suggested that too at some point.=C2=A0
    <= br>
    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderste= dt <torsten= @lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bri= stol, BS1 6FL
    t:=C2=A0+= 44 (0)117 280 5120

    <= div>
    Moneyhub Enterprise is a trading style of Moneyhub Financia= l Technology Limited which is authorised and regulated by the Financial Con= duct Authority ("FCA").=C2=A0Moneyhub Financial Technology is ent= ered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in England & Wales, compa= ny registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Fin= ancial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in = it other than by the addressee is unauthorised and unlawful. Whilst reasona= ble efforts are made to ensure that any attachments are virus-free, it is t= he recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorde= d for legitimate purposes relating to this company's business. Any opin= ions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techn= ology Limited or of any other group company.
    =

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bri= stol, BS1 6FL
    t:=C2=A0+= 44 (0)117 280 5120

    <= div>
    Moneyhub Enterprise is a trading style of Moneyhub Financia= l Technology Limited which is authorised and regulated by the Financial Con= duct Authority ("FCA").=C2=A0Moneyhub Financial Technology is ent= ered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in England & Wales, compa= ny registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Fin= ancial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in = it other than by the addressee is unauthorised and unlawful. Whilst reasona= ble efforts are made to ensure that any attachments are virus-free, it is t= he recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorde= d for legitimate purposes relating to this company's business. Any opin= ions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techn= ology Limited or of any other group company.
    =

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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



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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bri= stol, BS1 6FL
    t:=C2=A0+= 44 (0)117 280 5120

    <= div>
    Moneyhub Enterprise is a trading style of Moneyhub Financia= l Technology Limited which is authorised and regulated by the Financial Con= duct Authority ("FCA").=C2=A0Moneyhub Financial Technology is ent= ered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in England & Wales, compa= ny registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Fin= ancial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in = it other than by the addressee is unauthorised and unlawful. Whilst reasona= ble efforts are made to ensure that any attachments are virus-free, it is t= he recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorde= d for legitimate purposes relating to this company's business. Any opin= ions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techn= ology Limited or of any other group company.
    =

    Moneyhub Enterprise i= s a trading style of Moneyhub Financial Technology Limited which is authori= sed and regulated by the Financial Conduct Authority ("FCA"). Mon= eyhub Financial Technology is entered on the Financial Services Register (F= RN 809360) at https://registe= r.fca.org.uk/. Moneyhub Financial Technology is registered in En= gland & Wales, company registration number 06909772. Moneyhub Financial= Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple= Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

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





    --
    <= div dir=3D"ltr">
    Dave Tonge
    CTO
    3D"Mon=
    Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120
    <= /div>

    Moneyh= ub Enterprise is a trading style of Moneyhub Financial Technology Limited w= hich is authorised and regulated by the Financial Conduct Authority ("= FCA").=C2=A0Moneyhub Financial Technology is entered on the Financial = Services Register=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/= = . Moneyhub=C2=A0Financial T= echnology is registered in England & Wales, company registration number= =C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limi= ted 2019=C2=A0=C2=A9

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is conf= idential. Use of this email or of any information in it other than by the a= ddressee is unauthorised and unlawful. Whilst reasonable efforts are made t= o ensure that any attachments are virus-free, it is the recipient's sol= e responsibility to scan all attachments for viruses. All calls and emails = to and from this company may be monitored and recorded for legitimate purpo= ses relating to this company's business. Any opinions expressed in this= email (or in any attachments) are those of the author and do not necessari= ly represent the opinions of Moneyhub Financial Technology Limited or of an= y other group company.

    Moneyhub Enterprise is a = trading style of Moneyhub Financial Technology Limited which is authorised = and regulated by the Financial Conduct Authority ("FCA"). Moneyhu= b Financial Technology is entered on the Financial Services Register (FRN 8= 09360) at https://register.fc= a.org.uk/. Moneyhub Financial Technology is registered in Englan= d & Wales, company registration number 06909772. Moneyhub Financial Tec= hnology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Qua= y, 1 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachments) is subject to co= pyright, and the information in it is confidential. Use of this email or of= any information in it other than by the addressee is unauthorised and unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5t= h Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2= =A0+44 (0)117 28= 0 5120

    =
    Moneyhub Enterprise is a trading style of Moneyhub F= inancial Technology Limited which is authorised and regulated by the Financ= ial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology= is entered on the Financial Services Register=C2=A0(FRN= =C2=A0809360) at https://register.fca.= org.uk/. Moneyhub=C2=A0Financial Technology is registe= red in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000009f3d2405b692e09d-- From nobody Wed Dec 16 03:37:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011C93A09CD for ; Wed, 16 Dec 2020 03:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AurcMRUvDr7o for ; Wed, 16 Dec 2020 03:37:41 -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 C4B203A09C0 for ; Wed, 16 Dec 2020 03:37:39 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BGBbYvQ015339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Dec 2020 06:37:34 -0500 From: Justin Richer Message-Id: <9CA7546C-9A07-4F2D-9A1F-4755BDD3D1C9@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_7CC6F77E-E7A0-4592-8B0A-3346936EACD2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 16 Dec 2020 06:37:34 -0500 In-Reply-To: Cc: Dave Tonge , Dick Hardt , Fabien Imbault , Torsten Lodderstedt , txauth gnap , Steve Moore To: Warren Parad References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 16 Dec 2020 11:37:48 -0000 --Apple-Mail=_7CC6F77E-E7A0-4592-8B0A-3346936EACD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 16, 2020, at 5:15 AM, Warren Parad wrote: >=20 > #4 is a prereq for this discussion though. If the token is the = identifier of the grant then it must be in the url to avoid the problem = of arbitrary url construction. Of course the uri would be = https://as/grants/{grantIdentifier} = . And this is actually = independent of whether or not the token gets rotated. That=E2=80=99s not true: the identifier exposed to the client for some = purpose like grant extension doesn=E2=80=99t have to be the same = identifier that the AS uses for management. The latter is internal, and = exposing internal state to the protocol shouldn=E2=80=99t be a = requirement to the pattern.=20 >=20 > #3 The idea of a dynamic environment is important here, however the = argument doesn't justify having this being the same endpoint. Nothing = stops us from having two endpoints, one that requests an access token = separate from the ones that manage the grant resource. Nobody said this has to be the same endpoint. In fact, this structure is = being put in place to allow them to be separate endpoints. My original = design in XYZ used a single endpoint and exposed an internal identifier = of the ongoing grant request to the client within the protocol (the = transaction handle). Changing this to a properly abstracted and = protected API pattern allows much greater flexibility. The AS now has = the choice of how it wants to manage its own dispatching, without the = client needing to be aware of any of it since the client always does the = same thing. =E2=80=94 Justin >=20 > =09 > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . >=20 >=20 > On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge > wrote: > > Dave: which points changed your mind? >=20 > 1. The issue with re-using client authentication across endpoints in = the OAuth 2 world (token_endpoint_auth_methods_supported, = revocation_endpoint_auth_methods_supported, = introspection_endpoint_auth_methods_supported...) >=20 > 2. The clear articulation of the 3 different functions of the AS = (including the idea of a self-hosted AS) >=20 > 3. The aim to support a more dynamic environment where client = authentication only happens in the first interaction between the RC and = the AS >=20 > 4. The agreement that there should be further discussion on whether = this access token should be rotated, and whether it should be an = identifier of the grant. >=20 >=20 > On Wed, 16 Dec 2020 at 00:02, Dick Hardt > wrote: > Dave: which points changed your mind? >=20 > On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge > wrote: > Thanks for the detailed response. >=20 > I think you make the points well and I'm now in favour of the PR. > However I do think that to keep the consistency that keeps being = discussed, that the tokens shouldn't be rotated.=20 >=20 > I also think it would be good to have a discussion about "grant = management" and identifiers for a grant. >=20 > Dave >=20 > On Tue, 15 Dec 2020 at 17:30, Justin Richer > wrote: > On Dec 15, 2020, at 10:50 AM, Dave Tonge > wrote: >>=20 >> > The access token pattern has a lot of benefits, otherwise we = wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>=20 >> But what are the benefits in this particular use case? The = continuation API is not like any other API - it is integral to the AS. = There are quite a few extensions to OAuth that use client authentication = rather than access tokens. >=20 > Yes, and the propagation of that has lead to a mess in the OAuth = world. You=E2=80=99ve got re-definitions of client authentications at = all different endpoints, they=E2=80=99re technically allowed to vary = between endpoints (though I don=E2=80=99t know of it happening in = practice, that feels like a downgrade attack waiting to happen to = someone). Then there=E2=80=99s the fact that all the newest security = mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 don=E2=80=99t = rely on client authentication at all to achieve security. All of these = work without the client having credentials previously known to the AS, = and we already know that GNAP is going to need to live in this more = dynamic world. We need to think beyond what OAuth 2 has done in the = past, and especially from our perceptions and assumptions of the models = that drive OAuth 2=E2=80=99s decisions, lest we repeat its mistakes.=20 >=20 > Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2=80= =9D as a point. In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to = the server side, but in OAuth 2 we split that into the RS concept. Even = though in practice, a lot of RS=E2=80=99s are still integrated to the AS = in some fashion because it=E2=80=99s a single service, OAuth 2 is clear = about what=E2=80=99s expected to be known by each component. For the AS = as currently defined in GNAP, I=E2=80=99m seeing three distinct = functions. As per the Terminology discussion, we don=E2=80=99t have = explicit names for these yet: >=20 > - starting a request; this is an endpoint to kick things off; it = needs to be able to look up the rights asked for by the client (if it = knows the client at all ahead of time) and make initial decisions about = needed interaction and follow up > - continuing a request; this is an API that needs to know the context = of the request itself, including which key it=E2=80=99s bound to; this = is separate from any identity of the client and possibly the user, but = an AS implementation that has access to those elements can use them > - interacting with the user; this is front-facing and in OAuth today = is already deployed as a separate service in some places, we should = embrace that at the very least (but doing so formally is a separate = issue) >=20 > Why separate these in this way? There is immense power in having a = single consistent way to start the process. The =E2=80=9Ccontinuation = API=E2=80=9D gives us an HTTP-defined mechanism for managing a request = over time, including the simple case of returning information from the = front channel, but people have already raised the question of non-HTTP = and self-hosted AS=E2=80=99s, which would probably want a different kind = of continuation API to communicate to the AS. The same thing with = separating out the interaction: there are going to be a lot of different = ways to handle interaction out there, and not all of them will be = =E2=80=9Cintegral=E2=80=9D to the AS in the way that a simple = implementation might do. We=E2=80=99re defining a protocol based = strongly on HTTP and JSON, but we should structure it in such a way that = it can be extended and translated elsewhere in a clear way. >=20 >=20 > This all raises the question: if we can rely on a unique URL for = redirect-based interaction, why not here? The simple reason is that a = URL is the :only: mechanism we have in the front channel for passing = information, and we need to warn implementors against including = sensitive information in it, and we need to protect it with additional = items. We have access to more than just URLs when we=E2=80=99re dealing = with the continuation API, and we ought to make use of all of our tools = in ways that are consistent and make sense. >=20 >> =46rom a previous email the advantages I see are: >> - more data can be encoded in a token than in a uri (this seems more = of an edge case) >> - it can be an identifier for the grant (I don't agree with this) >=20 > It allows the parts above to live separately, even if they don=E2=80=99t= HAVE to. And it simplifies what we=E2=80=99re asking the client to do = by making it consistent with other parts of the ecosystem. The AS = offering an API doesn=E2=80=99t :have: to be different, and OpenID = Connect showed us, with the UserInfo Endpoint, that that=E2=80=99s very = much the case in practice.=20 >=20 > Having my client code do very similar things in slightly different = ways is not simpler. >=20 >>=20 >> Another question I have: do we envisage granting access tokens to the = RC that will allow it to manage multiple grants? =20 >=20 > I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t = been brought up as a use case to date.=20 >=20 >>=20 >> I also think there will be confusion with the signing being used for = different things. Maybe it just needs to be called out in the spec that: >>=20 >> Request 1: signature =3D client authentication >> Request 2+: signature =3D proof of possession for access token >>=20 >=20 > That=E2=80=99s more or less the intent of what=E2=80=99s in the = specification right now, and why all the signature methods, which are = used for both client auth and token possession, are all together in = section 8 and not separated by use. (With the caveat: it=E2=80=99s only = client authentication in the first request if the AS knows about the = client instance ahead of time, which isn=E2=80=99t always going to be = true.) That all can likely be made clearer, as is always the case with = spec text. But you can use the signature methods with and without access = tokens, and it only gets used without in an initial call where you = don=E2=80=99t :have: an access token to present. >=20 > Separating the different kinds of =E2=80=9Cclient authentication" out = in OAuth is the source of some real confusion. Like right now, what = happens if you try to combine a client assertion, signed request objects = for PAR, and DPoP proofs, all in a single request? All of these are = optional and all of them =E2=80=9Cdo client authentication=E2=80=9D in = some arguable fashion. I=E2=80=99ve worked on several systems and = implemented these things, and their interplay is really confusing to = manage and can go sideways really fast. And that=E2=80=99s just the work = for a single endpoint, this gets repeated for introspection, revocation, = CIBA, device, and on. >=20 > At the end of the day I=E2=80=99m in favor of giving the client = developers a very clear set of directions on what they need to do and = how they need to access things, and treating the continuation as a = token-bound API is, to me, the clearest pattern we can offer for this = piece. >=20 > =E2=80=94 Justin >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Tue, 15 Dec 2020 at 15:33, Justin Richer > wrote: >> I agree with Fabien that the persistent identifier is a separate = issue. The current spec re-uses the access token for this artifact, but = that=E2=80=99s potentially brittle and could be changed out for = something else. There=E2=80=99s an issue asking for expanding on the use = cases for this functionality (which hasn=E2=80=99t been addressed by = this PR): >>=20 >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = >>=20 >> A potentially-rotating URI would be just as brittle, and so having a = single codified identifier for this artifact would be useful, but it = does assume some things about the nature of the AS. Every other use the = client has to manage the ongoing request over time doesn=E2=80=99t need = an explicit identifier. Just like with OAuth-protected APIs, the server = can determine the context not just from the URI but from the rest of the = request, including the access token itself. This is both more common and = more powerful than a strict reading of REST designs. It also follows the = HATEOS principles as the entire HTTP request is taken into account, = including the access token and signature portions.=20 >>=20 >> I=E2=80=99ll also point out that the rotation of these credentials is = also filed as a separate issue that=E2=80=99s not being addressed right = now, so we can revisit that discussion separately: >>=20 >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = >>=20 >> As for the name, we could give it a different label. We have this = same pattern of issuing a resource-specific access token alongside a URL = in the Dynamic Registration specification, both in OAuth = (https://tools.ietf.org/html/rfc7592#section-3 = ) and OpenID Connect = (https://openid.net/specs/openid-connect-registration-1_0.html#Registratio= nResponse = ). Here it=E2=80=99s called the =E2=80=9Cregistration access = token=E2=80=9D =E2=80=94 but what=E2=80=99s important there, as it is = here, is that it=E2=80=99s not a different kind of artifact that the = client now has to figure out how to use, it=E2=80=99s an access token = plain and simple. In the OAuth world this is a bearer token, since = that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll be a = bound token, as that=E2=80=99s what we=E2=80=99re looking to build on. = This is also related to another future discussion about responses tying = an access token to a specific API that=E2=80=99s told to the client, as = we could potentially re-use those components and concepts here as well: >>=20 >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 = >>=20 >> And finally, no speculation on the complexity is needed: I = implemented this pattern several months ago during the design team = discussions when we were considering this pattern, and the code is all = online for people to see.=20 >>=20 >> https://github.com/bspk/oauth.xyz-java/ = >>=20 >> On the AS side, the most interesting code to this discussion is in = the TransactionEndpoint class: >>=20 >> = https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bsp= k/oauth/xyz/authserver/endpoint/TransactionEndpoint.java = >>=20 >> Here, you=E2=80=99ll see that on initial request, the server looks up = the client to see if it=E2=80=99s been registered, but after that, it = makes sure that the token and key are appropriate for the ongoing = request. =46rom the client side it=E2=80=99s even simpler. The = client=E2=80=99s got a small service function to manage the different = signature methods that are implemented, and all of them can take in an = optional access token:=20 >>=20 >> = https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bsp= k/oauth/xyz/http/SigningRestTemplateService.java = >>=20 >> The heavy lift is doing the actual signing, and you need that in = order to start the process anyway. Managing the access token as an = artifact to use at the API is completely trivial since the client = already needs to manage its own state internally to do any of this. And = note that all of this is changed from how it was before: Previously, the = XYZ Protocol had used a =E2=80=9Ctransaction handle=E2=80=9D returned by = the AS that the client would use to continue the request. However, this = simple model was limiting, and the design team adopted XAuth=E2=80=99s = model of continuation being an API. In doing so, we made it like all of = the other APIs the client is going to call: in the initial state, it = doesn=E2=80=99t have any kind of access rights, it=E2=80=99s just = calling. =46rom that initial call forward, the AS just needs to know = that the token and key match what it expects.=20 >>=20 >> In summary, my views are: >> - The access token pattern has a lot of benefits, otherwise we = wouldn=E2=80=99t have an entire OAuth ecosystem based on it >> - Magic URIs have a lot of drawbacks which are well understood; = while they can be mitigated, they can also be avoided >> - Continuation is an API, and treating it like the other kinds of = API the client would call makes sense >> - Calling this by a special name, like =E2=80=9Cgrant access = token=E2=80=9D or =E2=80=9Ccontinuation access token=E2=80=9D is fine, = but it should function like any other access token >> - The heavy lift for clients is on protecting the message = cryptographically, which they need to do anyway >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Dec 15, 2020, at 7:50 AM, Dave Tonge > wrote: >>>=20 >>> The persistent identifier is not a different issue, the current = access token is used to reference an existing grant = =20 >>>=20 >>> It may not be more difficult for a client to use an access token at = the AS / RS. But there is definitely an overhead on the client to manage = this separate access token.=20 >>>=20 >>>=20 >>>=20 >>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault = > wrote: >>> I think we always said the access token was different, and handled = as a bound token. >>>=20 >>> But it doesn't mean it's more difficult for the client that already = needs to be able to handle tokens anyway (bearer or not, both cases = could occur). It's mostly consolidating the logic. >>>=20 >>> You're anticipating a lot of issues which have no specific reason to = occur, such as "can't be used with the token management APIs?". The = management API is part of the same general flow. >>> Anticipating issues with rotation is useful, but there are also many = ways it can be hard to manage through a stateful approach too. And = fundamentally, having everything in a common model (both for the = internals of the AS and for the API calls) will help improve by a large = margin what is probably the weakest point in today's infrastructure. But = it's early to be definitive as to the downstream impact either way. =20 >>>=20 >>> As for a persistent identifier instead of a continuation API, and = generally the end of your message, it's a totally unrelated issue to = this PR, so I suggest we don't discuss that here, but in a separate = issue if needed. >>>=20 >>> Fabien >>>=20 >>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge > wrote: >>> So we've established that this is a different access token, that = requires different handling at the client. So keeping it could cause = more confusion? >>>=20 >>> As an RC, I will have to store the continue `uri` as although it = could be static it could also be dynamic. Why do I need to store an = access token as well. It brings me no benefit as an RC, in fact it = brings more complexity. As I will now need to manage multiple types of = tokens with different lifecycles: >>>=20 >>> Continuation token=20 >>> - can only be used at the continue endpoint (the name of which is = confusing as I can use this endpoint to revoke a grant or get metadata = on the grant). >>> - may be rotated each time it is used, or may not be >>> - provided in the `continue` section of the response >>> - must be sender-constrained >>> - can't be used with the token management APIs? >>> - can be used to identify the grant when making subsequent grants >>>=20 >>> Access token(s) to use at RS >>> - can only be used at the specified RS >>> - may be sender constrained >>> - when used at the RS, will not result in rotation >>>=20 >>> =46rom my perspective, most use-cases will require the RC to have a = persistent identifier for the grant. Why not bring this into the = protocol and let the AS provide this persistent identifier (through the = form of the continue uri). Using a rotating access token as a persistent = identifier doesn't seem like the right choice.=20 >>>=20 >>> I see no security benefit to having the continuation access token. = It doesn't matter if the continue uri leaks as it is useless without an = accompanying signature, i.e. any security benefit of having an access = token is already provided by having a signature. >>>=20 >>> The only benefits that I can see are: >>> - If the AS wants to be fully stateless, then you can encode more = data in a token than in a uri >>> - If the AS wants to have a static endpoint for CRUD operations on = the grant >>> - To allow the AS to identity a previous grant >>>=20 >>> If we dropped the access token for the continue endpoint and rather = mandated a dynamic uri this would make things conceptually easier to = understand, easier for the RC to implement, easier to debug and less = chance of errors when rotating tokens (i.e. race conditions could be = quite likely if the AS always rotates the token) >>>=20 >>> One-off grant with no continuation or ongoing management: >>> RC sends signature and metadata, no `continue` response provided, = therefore no grant management possible >>>=20 >>> Grant with ongoing management >>> RC sends signature and metadata, AS responds with a continue uri = that has these purposes: >>> - can be used by the RC to continue/update, read or revoke the = grant >>> - can be used by the RC when making a new grant to identify the = previous grant >>>=20 >>> As an RC the only permanent items I need to store are: >>> - the continue uri associated with the grant >>> - any access tokens I receive for the grant >>>=20 >>> Dave >>>=20 >>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault = > wrote: >>> Hi Torsten,=20 >>>=20 >>> You're right on both accounts.=20 >>> - for the first remark, it fits quite nicely the init request / = continuation pattern=20 >>> - for the second remark, it is a sort of handle for the continuation = request, which will eventually lead to the issuance or refresh of = standard access tokens=20 >>>=20 >>> Having a specific name is a possibility, I actually suggested that = too at some point.=20 >>>=20 >>> Fabien >>>=20 >>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt = > wrote: >>> Hi Fabien,=20 >>>=20 >>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault = >: >>> >=20 >>> > Hi, >>> >=20 >>> > On the contrary your feedback is most welcome.=20 >>> >=20 >>> > It doesn't accept any token, it needs the particular token as = described in 3.1 and which is not a bearer token (that's what the "key" = : true parameter is supposed to convey).=20 >>> >=20 >>> > Let us know if you need more clarifications.=20 >>>=20 >>> Thanks for the clarification. I think only accepting this kind of = token at the continuation is a good idea otherwise the AS would need to = be able to parse and understand all sorts of access tokens. >>>=20 >>> Conceptually, I like the idea to treat the continuation as another = kind of resource. However, here are some observations I want to share = with you:=20 >>> - This resource is different as it will issue other access tokens = (of this kind) to be used in subsequent continuation requests. This = requires different handing on the client side. >>> - This access token (if I understand correctly) is (or at least = feels like) a handle for the underlying grant. So it is kind of the = super access token to obtain other access tokens.=20 >>>=20 >>> I would consider using a different term to refer to this special = access token, grant token or grant handle for example, in order to = prevent confusion.=20 >>>=20 >>> best regards, >>> Torsten.=20 >>>=20 >>>=20 >>> >=20 >>> > Best >>> > Fabien=20 >>> >=20 >>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt = > a =C3=A9crit = : >>> > Hi all, >>> >=20 >>> > I didn=E2=80=99t follow GNAP closely so bear with me if me = question seems naive. >>> >=20 >>> > After having skimmed through the current draft and the PR, I=E2=80=98= m not sure whether the continuation requests accepts any access token = issued to the RC or the particular access token returned in the = =E2=80=9Econtinue=E2=80=9C element in section 3.1.. >>> >=20 >>> > Can you please shed some light on this? >>> >=20 >>> > kind regards, >>> > Torsten. >>> >=20 >>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault = >: >>> >>=20 >>> >> =EF=BB=BF >>> >> You're completely right. Allowing the dev to be lazy is a very = good thing in general, because it's what we know will work :-)=20 >>> >>=20 >>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore = > a =C3=A9crit : >>> >> Hi Fabien, >>> >>=20 >>> >> For #3) Even after I typed out the hypothetical attack, that was = sort of in the back of my mind, it isn't a huge risk there. So I = actually agree with Dick there. Something doesn't sit right with me for = the unique URL solution, so I don't like it and came up with a = hypothetical that seems like it could be a down side. >>> >>=20 >>> >> I still think the access token model with the signed request is = the way I'd like to go, because again, it's a mechanism I'd be = implementing anyway to talk to any 'normal' resource. The fact is there = is _something_ representing context that has to pass back and forth = here, whether that is an access token (which I feel like is more = flexible for extensions etc), a unique url, or even a cookie sent in the = cookie header. So just to re-iterate, I'm a +1 on this pull request, = speaking as a lazy developer ;) >>> >> -steve >>> >>=20 >>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault = > wrote: >>> >> Again speaking in my own name here.=20 >>> >>=20 >>> >> Dick, we know you'd prefer to have a different design, but this = PR shouldn't be about that.=20 >>> >>=20 >>> >> Back on your 3 items : >>> >>=20 >>> >> 1) yes we could make pre-register mandatory, but we already = decided that wouldn't be how that would work. We have a client instance = that allows a more generic and flexible pattern (which BTW also allows = what you want)=20 >>> >>=20 >>> >> 2) instead of blame arguments of who's less = restful/HATEOAS/whatever that have the tenancy to flame conversations, I = suggest we speak in less abstract terms and ask ourselves what that = means in practice for devs. Stephen and several others (myself included) = have expressed that it wouldn't be harder to implement, it would even = simplify things quite a lot. If you disagree please send us a code = sample to really show that point by example, because that's really not = obvious.=20 >>> >>=20 >>> >> 3) "If someone has the client credentials, they can impersonate = the client, and all bets are off." Are you seriously making this = argument? Because if you have a better proposal than using cryptographic = keys, I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digital = communications.=20 >>> >> =20 >>> >> And more importantly you never responded to the issues of how to = avoid the security pitfalls of what you proposed.=20 >>> >>=20 >>> >> Fabien=20 >>> >>=20 >>> >>=20 >>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = > a =C3=A9crit : >>> >>=20 >>> >>=20 >>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore > wrote: >>> >> But from the spec: >>> >> " >>> >> When sending a non-continuation request to the AS, the RC MUST = identify itself by including the client field of the request... >>> >> ... >>> >> key (object / string) : The public key of the RC to be used in = this request as described in {{request-key}}. This field is REQUIRED.=20 >>> >> ... >>> >> " >>> >> So on the initial request, the key will be there.=20 >>> >>=20 >>> >> The client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object. >>> >> =20 >>> >>=20 >>> >> If you don't have the access token, then how do you differentiate = between two requests from the same web application by two different = users? Is the web application supposed to have different credentials for = every request? >>> >>=20 >>> >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the = usually RESTful pattern that the resource (the grant request) has an = URI. >>> >>=20 >>> >> =20 >>> >> So in this case, the easy way out is to pass the access token to = the client, who then, as i stated before, treats the continue request as = a RS call (albeit a specialized version of the RS where the RS is the = AS) OR to use the unique URL,=20 >>> >> but that seems open to a brute force attack by a malicious RC. = (What would be the point of that attack, I don't know, I guess if = someone had the client credentials but not any subjects/resources they = could try to intercept the grant via continue... I just don't feel right = locking things down to unique URLs that way.) >>> >>=20 >>> >> If someone has the client credentials, they can impersonate the = client, and all bets are off. >>> >>=20 >>> >> LOTS of RS servers return a resource specific URL -- my proposal = is no different. >>> >>=20 >>> >>=20 >>> >> =20 >>> >> -steve >>> >>=20 >>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt > wrote: >>> >> Hi Stephen >>> >>=20 >>> >> The client is signing the first request. The key *might* be in = the body. The client is signing all the subsequent requests as well. The = "access token" is not needed by the client to prove it is authorized as = the client is proving it is the same client again. >>> >>=20 >>> >> In other words, I don't see the need for an access token, so it = does not need to be put in a URL or an auth header. >>> >>=20 >>> >> If a developer really, really wants to hand context back to the = client for subsequent calls, they can put it in the URL or some other = method. Putting it in the HTTP Authorization header is confusing because = it is NOT an access token -- it is the context of the request. >>> >>=20 >>> >> =E1=90=A7 >>> >>=20 >>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore > wrote: >>> >> Even though I've only been lightly following things, I feel the = need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...=20 >>> >>=20 >>> >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of = the Authorization header) >>> >> At this point that request, represented by the continue URL + = "Access Token", from my lazy developer standpoint, is a Resource = Endpoint and Access Token, and the AS is acting as a specialized RS in = this case. >>> >> So my client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a = token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client. >>> >> Personally I like that, because if I have an access_token, I = already think "Put it in the auth header."=20 >>> >>=20 >>> >> So my vote would be +1 for the pull request at this time. >>> >> -steve >>> >>=20 >>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt > wrote: >>> >> inline ...=20 >>> >>=20 >>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer > wrote: >>> >> Others had already responded to this previous thread, but I = wanted to add a couple points to clarify some things. >>> >>=20 >>> >>> 3) What the client has to do with the "access token" is not the = same as access tokens for an RS. The client gets a new "access token" = for each grant request, and for each API call to the AS, and the client = learns it can not make any more API calls for that specific request when = it does not get an "access token" back. This is a completely different = design pattern than calling an RS API with an access token, and is a new = design pattern for calling APIs. This adds complexity to the client that = it would not normally have, and I don't think GNAP is the right place to = start a new design pattern. >>> >>>=20 >>> >>=20 >>> >> I=E2=80=99m not sure what you mean by these being different =E2=80=94= the whole point of the design is that the client would be doing the = same thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical. >>> >>=20 >>> >> The client is getting the "access token" from its API. It is not = using an "access_token" in other API calls to the AS. >>> >> =20 >>> >>=20 >>> >> Rotation of the access token and artifacts for ongoing = continuation responses is a separate issue to be discussed: = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = >>> >>=20 >>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right = place to have new designs =E2=80=94 not that this is one. >>> >>=20 >>> >> You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me. >>> >> =20 >>> >>=20 >>> >>> 4) Clients that only want claims from the AS and no access = tokens will be required to support an API calling mechanism they would = not have to support otherwise.=20 >>> >>=20 >>> >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign = the initial request in some fashion, and it will sign the continuation = request in the same exact fashion, but now include an access token in = that request.=20 >>> >>=20 >>> >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is = extra work providing no value. >>> >>=20 >>> >> Also, any client authentication mechanism that wants to use the = HTTP Authentication header is precluded from using it. >>> >>=20 >>> >> =20 >>> >>=20 >>> >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, = but OAuth today shows us the immense value of getting access tokens for = calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern. >>> >>=20 >>> >>>=20 >>> >>> 5) If the AS does not provide an "access token", there is no = mechanism for a client to delete the request, as the client is not = allowed to make a call without an "access token". >>> >>=20 >>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. >>> >>=20 >>> >> There is nuance in that intention. A related concern is that = deleting a request does not seem like it is a "continue" operation. >>> >> =20 >>> >>=20 >>> >>>=20 >>> >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to = identifying a request. While one AS may provide a unique URL for each = grant request, another AS may use a persistent "access token" to = identify the grant request, and other ASs may issue a new "access token" = on each API call, providing no persistent identifier for the request. >>> >>=20 >>> >> Debugging and auditing this kind of thing are functions of the = AS. How is interoperability harmed by different ASs having different = methods to identify their internal data elements? The client doesn=E2=80=99= t need any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps for continuing the negotiation. >>> >>=20 >>> >> Debugging between the client and the AS was what I was referring = to. How does a client developer identify the request when communicating = to the AS developer. Seems complicated. >>> >> =20 >>> >> =E1=90=A7 >>> >> --=20 >>> >> TXAuth mailing list >>> >> TXAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/txauth = >>> >> =E1=90=A7 >>> >> --=20 >>> >> TXAuth mailing list >>> >> TXAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/txauth = >>> >> --=20 >>> >> TXAuth mailing list >>> >> TXAuth@ietf.org >>> >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJ= YtSpI = >>>=20 >>> --=20 >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>>=20 >>> --=20 >>> Dave Tonge >>> CTO >>> = >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, = BS1 6FL = t: +44 (0)117 280 5120 >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA = .=20 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Dave Tonge >>> CTO >>> = >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, = BS1 6FL = t: +44 (0)117 280 5120 >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>=20 >>> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA = .=20 >>>=20 >>> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>>=20 >>>=20 >>=20 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >> --=20 >> Dave Tonge >> CTO >> = >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, = BS1 6FL = t: +44 (0)117 280 5120 >>=20 >> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >>=20 >> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>=20 >> Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA = .=20 >>=20 >> DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >>=20 >>=20 >=20 >=20 >=20 > --=20 > Dave Tonge > CTO > = > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL = t: +44 (0)117 280 5120 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA = .=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 >=20 >=20 > --=20 > Dave Tonge > CTO > = > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL > t: +44 (0)117 280 5120 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_7CC6F77E-E7A0-4592-8B0A-3346936EACD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 16, 2020, at 5:15 AM, Warren Parad <wparad@rhosys.ch> = wrote:

    #4 is = a prereq for this discussion though. If the token is the identifier of = the grant then it must be in the url to avoid the problem of arbitrary = url construction. Of course the uri would be https://as/grants/{grantIdentifier}. And this is = actually independent of whether or not the token gets = rotated.

    That=E2=80= =99s not true: the identifier exposed to the client for some purpose = like grant extension doesn=E2=80=99t have to be the same identifier that = the AS uses for management. The latter is internal, and exposing = internal state to the protocol shouldn=E2=80=99t be a requirement to the = pattern. 


    #3 The idea of a = dynamic environment is important here, however the argument doesn't = justify having this being the same endpoint. Nothing stops us from = having two endpoints, one that requests an access token separate from = the ones that manage the grant = resource.

    Nobody said this has to be the same endpoint. In = fact, this structure is being put in place to allow them to be separate = endpoints. My original design in XYZ used a single endpoint and exposed = an internal identifier of the ongoing grant request to the client within = the protocol (the transaction handle). Changing this to a properly = abstracted and protected API pattern allows much greater flexibility. = The AS now has the choice of how it wants to manage its own dispatching, = without the client needing to be aware of any of it since the client = always does the same thing.

     =E2=80= =94 Justin


    Warren Parad
    Founder, = CTO
    Secure your user data and complete your = authorization architecture. Implement Authress.


    On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    > Dave: = which points changed your mind?

    1. The issue with re-using client = authentication across endpoints in the OAuth 2 world = (token_endpoint_auth_methods_supported, revocation_endpoint_auth_meth= ods_supported, introspection_endpoint_auth_methods_supported...)

    2. The clear articulation of the = 3 different functions of the AS (including the idea of a self-hosted = AS)

    3. The aim = to support a more dynamic environment where client authentication only = happens in the first interaction between the RC and the AS

    4. The = agreement that there should be further discussion on whether this access = token should be rotated, and whether it should be an identifier of the = grant.


    On Wed, 16 = Dec 2020 at 00:02, Dick Hardt <dick.hardt@gmail.com> wrote:
    Dave: which points changed your mind?

    On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    Thanks for the detailed = response.

    I think you make the points well and I'm now in favour of = the PR.
    However I do think that to keep = the consistency that keeps being discussed, that the tokens shouldn't be = rotated. 

    I also think it would be good to have a discussion about = "grant management" and identifiers for a grant.

    Dave

    On Tue, 15 = Dec 2020 at 17:30, Justin Richer <jricher@mit.edu> wrote:
    On Dec 15, 2020, at 10:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    > The access token pattern has a lot of benefits, = otherwise we wouldn=E2=80=99t have an entire OAuth ecosystem based on = it

    But what are the benefits in = this particular use case? The continuation API is not = like any other API - it is integral to the AS. There are quite a few = extensions to OAuth that use client authentication rather than access = tokens.

    Yes, and the propagation of that has = lead to a mess in the OAuth world. You=E2=80=99ve got re-definitions of = client authentications at all different endpoints, they=E2=80=99re = technically allowed to vary between endpoints (though I don=E2=80=99t = know of it happening in practice, that feels like a downgrade attack = waiting to happen to someone). Then there=E2=80=99s the fact that all = the newest security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS = =E2=80=94 don=E2=80=99t rely on client authentication at all to achieve = security. All of these work without the client having credentials = previously known to the AS, and we already know that GNAP is going to = need to live in this more dynamic world. We need to think beyond what = OAuth 2 has done in the past, and especially from our perceptions and = assumptions of the models that drive OAuth 2=E2=80=99s decisions, lest = we repeat its mistakes. 

    Also, I want to challenge this idea of = =E2=80=9Cintegral to the AS=E2=80=9D as a point. In OAuth 1, the API was = =E2=80=9Cintegral=E2=80=9D to the server side, but in OAuth 2 we split = that into the RS concept. Even though in practice, a lot of RS=E2=80=99s = are still integrated to the AS in some fashion because it=E2=80=99s a = single service, OAuth 2 is clear about what=E2=80=99s expected to be = known by each component. For the AS as currently defined in GNAP, I=E2=80=99= m seeing three distinct functions. As per the Terminology discussion, we = don=E2=80=99t have explicit names for these yet:

     - starting a request; this is an = endpoint to kick things off; it needs to be able to look up the rights = asked for by the client (if it knows the client at all ahead of time) = and make initial decisions about needed interaction and follow = up
     - continuing a request; this is an API that needs to know = the context of the request itself, including which key it=E2=80=99s = bound to; this is separate from any identity of the client and possibly = the user, but an AS implementation that has access to those elements can = use them
     - interacting with the user; this is = front-facing and in OAuth today is already deployed as a separate = service in some places, we should embrace that at the very least (but = doing so formally is a separate issue)

    Why separate these in this way? There = is immense power in having a single consistent way to start the process. = The =E2=80=9Ccontinuation API=E2=80=9D gives us an HTTP-defined = mechanism for managing a request over time, including the simple case of = returning information from the front channel, but people have already = raised the question of non-HTTP and self-hosted AS=E2=80=99s, which = would probably want a different kind of continuation API to communicate = to the AS. The same thing with separating out the interaction: there are = going to be a lot of different ways to handle interaction out there, and = not all of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way = that a simple implementation might do. We=E2=80=99re defining a protocol = based strongly on HTTP and JSON, but we should structure it in such a = way that it can be extended and translated elsewhere in a clear = way.

    This all raises the question: if we can rely on a unique URL = for redirect-based interaction, why not here? The simple reason is that = a URL is the :only: mechanism we have in the front channel for passing = information, and we need to warn implementors against including = sensitive information in it, and we need to protect it with additional = items. We have access to more than just URLs when we=E2=80=99re dealing = with the continuation API, and we ought to make use of all of our tools = in ways that are consistent and make sense.

    =46ro= m a previous email the advantages I see are:
     - more data can be encoded in a token than = in a uri (this seems more of an edge case)
     - it can be an identifier for the grant (I = don't agree with this)

    It allows the parts above to live = separately, even if they don=E2=80=99t HAVE to. And it simplifies what = we=E2=80=99re asking the client to do by making it consistent with other = parts of the ecosystem. The AS offering an API doesn=E2=80=99t :have: to = be different, and OpenID Connect showed us, with the UserInfo Endpoint, = that that=E2=80=99s very much the case in practice. 

    Having my client code do = very similar things in slightly different ways is not simpler.


    Another question I = have: do = we envisage granting access tokens to the RC that will allow it to = manage multiple = grants?  

    I don=E2=80=99t see that happening, = personally, and it hasn=E2=80=99t been brought up as a use case to = date. 


    I also think there will be = confusion with the signing being used for different things. Maybe it = just needs to be called out in the spec that:

    Request 1: signature =3D client = authentication
    Request 2+: signature =3D= proof of possession for access token


    That=E2=80=99s more or = less the intent of what=E2=80=99s in the specification right now, and = why all the signature methods, which are used for both client auth and = token possession, are all together in section 8 and not separated by = use.  (With the caveat: it=E2=80=99s only client authentication in = the first request if the AS knows about the client instance ahead of = time, which isn=E2=80=99t always going to be true.) That all can likely = be made clearer, as is always the case with spec text. But you can use = the signature methods with and without access tokens, and it only gets = used without in an initial call where you don=E2=80=99t :have: an access = token to present.

    Separating the different kinds of =E2=80=9Cclient = authentication" out in OAuth is the source of some real confusion. Like = right now, what happens if you try to combine a client assertion, signed = request objects for PAR, and DPoP proofs, all in a single request? All = of these are optional and all of them =E2=80=9Cdo client = authentication=E2=80=9D in some arguable fashion. I=E2=80=99ve worked on = several systems and implemented these things, and their interplay is = really confusing to manage and can go sideways really fast. And that=E2=80= =99s just the work for a single endpoint, this gets repeated for = introspection, revocation, CIBA, device, and on.

    At the end of the day I=E2=80=99m in = favor of giving the client developers a very clear set of directions on = what they need to do and how they need to access things, and treating = the continuation as a token-bound API is, to me, the clearest pattern we = can offer for this piece.

     =E2=80=94 Justin









    On Tue, 15 = Dec 2020 at 15:33, Justin Richer <jricher@mit.edu> wrote:
    I agree with Fabien that the persistent identifier is a = separate issue. The current spec re-uses the access token for this = artifact, but that=E2=80=99s potentially brittle and could be changed = out for something else. There=E2=80=99s an issue asking for expanding on = the use cases for this functionality (which hasn=E2=80=99t been = addressed by this PR):

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

    A = potentially-rotating URI would be just as brittle, and so having a = single codified identifier for this artifact would be useful, but it = does assume some things about the nature of the AS. Every other use the = client has to manage the ongoing request over time doesn=E2=80=99t need = an explicit identifier. Just like with OAuth-protected APIs, the server = can determine the context not just from the URI but from the rest of the = request, including the access token itself. This is both more common and = more powerful than a strict reading of REST designs. It also follows the = HATEOS principles as the entire HTTP request is taken into account, = including the access token and signature portions. 

    I=E2=80=99ll also point = out that the rotation of these credentials is also filed as a separate = issue that=E2=80=99s not being addressed right now, so we can revisit = that discussion separately:

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

    As for the = name, we could give it a different label. We have this same pattern of = issuing a resource-specific access token alongside a URL in the Dynamic = Registration specification, both in OAuth (https://tools.ietf.org/html/rfc7592#section-3) and OpenID = Connect (https://openid.net/specs/openid-connect-registration-1_0.html#R= egistrationResponse). Here it=E2=80=99s called the =E2=80=9Cregistrati= on access token=E2=80=9D =E2=80=94 but what=E2=80=99s important there, = as it is here, is that it=E2=80=99s not a different kind of artifact = that the client now has to figure out how to use, it=E2=80=99s an access = token plain and simple. In the OAuth world this is a bearer token, since = that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll be a = bound token, as that=E2=80=99s what we=E2=80=99re looking to build on. = This is also related to another future discussion about responses tying = an access token to a specific API that=E2=80=99s told to the client, as = we could potentially re-use those components and concepts here as = well:

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

    And finally, = no speculation on the complexity is needed: I implemented this pattern = several months ago during the design team discussions when we were = considering this pattern, and the code is all online for people to = see. 

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

    On the AS side, the most = interesting code to this discussion is in the TransactionEndpoint = class:

    https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/= java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java

    Here, you=E2=80=99= ll see that on initial request, the server looks up the client to see if = it=E2=80=99s been registered, but after that, it makes sure that the = token and key are appropriate for the ongoing request. =46rom the client = side it=E2=80=99s even simpler. The client=E2=80=99s got a small service = function to manage the different signature methods that are implemented, = and all of them can take in an optional access token: 

    https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/= java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java

    The heavy lift is doing = the actual signing, and you need that in order to start the process = anyway. Managing the access token as an artifact to use at the API is = completely trivial since the client already needs to manage its own = state internally to do any of this. And note that all of this is changed = from how it was before: Previously, the XYZ Protocol had used a = =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the client = would use to continue the request. However, this simple model was = limiting, and the design team adopted XAuth=E2=80=99s model of = continuation being an API. In doing so, we made it like all of the other = APIs the client is going to call: in the initial state, it doesn=E2=80=99t= have any kind of access rights, it=E2=80=99s just calling. =46rom that = initial call forward, the AS just needs to know that the token and key = match what it expects. 

    In summary, my views are:
     - The access token pattern has a lot of benefits, = otherwise we wouldn=E2=80=99t have an entire OAuth ecosystem based on = it
     - Magic URIs have a lot of drawbacks which = are well understood; while they can be mitigated, they can also be = avoided
     - Continuation is an API, and = treating it like the other kinds of API the client would call makes = sense
     - Calling this by a special name, like = =E2=80=9Cgrant access token=E2=80=9D or =E2=80=9Ccontinuation access = token=E2=80=9D is fine, but it should function like any other access = token
     - The heavy lift for clients is on = protecting the message cryptographically, which they need to do = anyway

     =E2= =80=94 Justin


    On Dec = 15, 2020, at 7:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    The = persistent identifier is not a different issue, the current access = token is used to reference an existing = grant 

    It may not be more difficult for a client to use an access token at the AS / = RS. But there is definitely an overhead on the client to manage this = separate access token. 



    On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I think we always said the access token was = different, and handled as a bound token.

    But it doesn't mean it's more difficult = for the client that already needs to be able to handle tokens anyway = (bearer or not, both cases could occur). It's mostly consolidating the = logic.

    You're anticipating a lot of issues which have no specific = reason to occur, such as "can't be used with the token = management APIs?". The management API is part of the same general = flow.
    Anticipating issues = with rotation is useful, but there are also many ways it can be hard to = manage through a stateful approach too. And fundamentally, having = everything in a common model (both for the internals of the AS and for = the API calls) will help improve by a large margin what is probably the = weakest point in today's infrastructure. But it's early to be definitive = as to the downstream impact either way.   

    As for a persistent = identifier instead of a continuation API, and generally the end of your = message, it's a totally unrelated issue to this PR, so I suggest we = don't discuss that here, but in a separate issue if = needed.

    Fabien

    On Tue, Dec = 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established that this is = a different access token, that requires different handling at the = client. So keeping it could cause more confusion?

    As an RC, I = will have to store the continue `uri` as although it could be static it = could also be dynamic. Why do I need to store an access token as = well. It brings me no benefit as an RC, in fact it brings more = complexity. As I will now need to manage multiple types of tokens with = different lifecycles:

    Continuation = token 
      - can only be used at the = continue endpoint (the name of which is confusing as I can use this = endpoint to revoke a grant or get metadata on the grant).
     - may be rotated each time it is used, or may not = be
     - provided in the = `continue` section of the response
     - = must be sender-constrained
     - = can't be used with the token management APIs?
     - can be used to identify the grant when making = subsequent grants

    Access token(s) to use at RS
      - can only be used at the = specified RS
      - may be sender = constrained
      - when used at the RS, = will not result in rotation

    =46rom my perspective, most = use-cases will require the RC to have a persistent identifier for the = grant. Why not bring this into the protocol and let the AS provide this = persistent identifier (through the form of the continue uri). Using a = rotating access token as a persistent identifier doesn't seem like the = right choice. 

    I see no security benefit to = having the continuation access token. It doesn't matter if the continue = uri leaks as it is useless without an accompanying signature, i.e. any = security benefit of having an access token is already provided by having = a signature.

    The only benefits that I can see are:
     - If the AS wants to be fully stateless, then you can = encode more data in a token than in a uri
     - If the AS wants to have a static endpoint for CRUD = operations on the grant
     - To = allow the AS to identity a previous grant

    If we = dropped the access token for the continue endpoint and rather mandated a = dynamic uri this would make things conceptually easier to understand, = easier for the RC to implement, easier to debug and less chance of = errors when rotating tokens (i.e. race conditions could be quite likely = if the AS always rotates the token)

    One-off grant with no = continuation or ongoing management:
    RC sends = signature and metadata, no `continue` response provided, therefore no = grant management possible

    Grant with ongoing = management
    RC sends signature and metadata, = AS responds with a continue uri that has these purposes:
     - can be used by the RC to continue/update, read or = revoke the grant
     - can be used by the RC = when making a new grant to identify the previous grant

    As an RC = the only permanent items I need to store are:
     - the continue uri associated with the = grant
     - any access tokens I = receive for the grant

    Dave

    On Tue, 15 = Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Torsten, 

    You're right on both = accounts. 
    - for the first remark, it fits = quite nicely the init request  / continuation = pattern 
    - for the second remark, it is a sort = of handle for the continuation request, which will eventually lead = to the issuance or refresh of standard access tokens 

    Having a = specific name is a possibility, I actually suggested that too at = some point. 

    Fabien

    On Tue, Dec = 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi = Fabien, 

    > Am 12.12.2020 um 12:06 schrieb Fabien = Imbault <fabien.imbault@gmail.com>:
    > 
    > Hi,
    > 
    > On the contrary your feedback is most welcome. 
    > 
    > It = doesn't accept any token, it needs the particular token as described in = 3.1 and which is not a bearer token (that's what the "key" : true = parameter is supposed to convey). 
    > 
    > Let us = know if you need more clarifications. 

    Thanks for the clarification. I think only accepting this = kind of token at the continuation is a good idea otherwise the AS would = need to be able to parse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the = continuation as another kind of resource. However, here are some = observations I want to share with you: 
    - This = resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires = different handing on the client side.
    - This access token = (if I understand correctly) is (or at least feels like) a handle for the = underlying grant. So it is kind of the super access token to obtain = other access tokens. 
    I would consider using a different term to = refer to this special access token, grant token or grant handle for = example, in order to prevent confusion. 

    best regards,
    Torsten. 


    > 
    > Best
    > Fabien 
    > 
    > Le sam. = 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.net> a =C3=A9crit :
    > Hi all,
    > 
    > I = didn=E2=80=99t follow GNAP closely so bear with me if me question seems = naive.
    > 
    > After = having skimmed through the current draft and the PR, I=E2=80=98m not = sure whether the continuation requests accepts any access token issued = to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    > 
    > Can you = please shed some light on this?
    > 
    > kind = regards,
    > Torsten.
    > 
    >> Am = 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com>:
    >> 
    >> = =EF=BB=BF
    >> You're completely right. Allowing the = dev to be lazy is a very good thing in general, because it's what we = know will work :-) 
    >> 
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen = Moore <srmoore@gmail.com> a =C3=A9crit :
    >>= Hi Fabien,
    >> 
    >> For = #3) Even after I typed out the hypothetical attack, that was sort of in = the back of my mind, it isn't a huge risk there. So I actually agree = with Dick there. Something doesn't sit right with me for the unique URL = solution, so I don't like it and came up with a hypothetical that seems = like it could be a down side.
    >> 
    >> I = still think the access token model with the signed request is the way = I'd like to go, because again, it's a mechanism I'd be implementing = anyway to talk to any 'normal' resource. The fact is there is = _something_ representing context that has to pass back and forth here, = whether that is an access token (which I feel like is more flexible for = extensions etc), a unique url, or even a cookie sent in the cookie = header. So just to re-iterate, I'm a +1 on this pull request, speaking = as a lazy developer ;)
    >> -steve
    >> 
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault = <fabien.imbault@gmail.com> wrote:
    >> = Again speaking in my own name here. 
    >> 
    >> = Dick, we know you'd prefer to have a different design, but this PR = shouldn't be about that. 
    >> 
    >> = Back on your 3 items :
    >> 
    >> 1) = yes we could make pre-register mandatory, but we already decided that = wouldn't be how that would work. We have a client instance that allows a = more generic and flexible pattern (which BTW also allows what you = want) 
    >> 
    >> 2) instead of blame arguments of who's less = restful/HATEOAS/whatever that have the tenancy to flame conversations, I = suggest we speak in less abstract terms and ask ourselves what that = means in practice for devs. Stephen and several others (myself included) = have expressed that it wouldn't be harder to implement, it would even = simplify things quite a lot. If you disagree please send us a code = sample to really show that point by example, because that's really not = obvious. 
    >> 
    >> 3) "If someone has the client credentials, they can = impersonate the client, and all bets are off." Are you seriously making = this argument? Because if you have a better proposal than using = cryptographic keys, I'm all hears. You make it look like there's a = problem, while in reality we're only relying on the basic assumption of = all modern digital communications. 
    >>  
    >> And = more importantly you never responded to the issues of how to avoid the = security pitfalls of what you proposed. 
    >> 
    >> = Fabien 
    >> 
    >> 
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = <dick.hardt@gmail.com> a =C3=A9crit :
    >> 
    >> 
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But = from the spec:
    >> "
    >> When = sending a non-continuation request to the AS, the RC MUST identify = itself by including the client field of the request...
    >> ...
    >> key (object / string) : = The public key of the RC to be used in this request as described in = {{request-key}}. This field is REQUIRED. 
    >> = ...
    >> "
    >> So on the initial = request, the key will be there. 
    >> 
    >> The = client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object.
    >>  
    >> 
    >> If = you don't have the access token, then how do you differentiate between = two requests from the same web application by two different users? Is = the web application supposed to have different credentials for every = request?
    >> 
    >> The = AS returns a URI for manipulating the request. I would change the spec = so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >> 
    >>  
    >> So = in this case, the easy way out is to pass the access token to the = client, who then, as i stated before, treats the continue request as a = RS call (albeit a specialized version of the RS where the RS is the AS) = OR to use the unique URL, 
    >> but = that seems open to a brute force attack by a malicious RC. (What would = be the point of that attack, I don't know, I guess if someone had the = client credentials but not any subjects/resources they could try to = intercept the grant via continue... I just don't feel right locking = things down to unique URLs that way.)
    >> 
    >> If = someone has the client credentials, they can impersonate the client, and = all bets are off.
    >> 
    >> = LOTS of RS servers return a resource specific URL -- my proposal is no = different.
    >> 
    >> 
    >>  
    >> = -steve
    >> 
    >> On = Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    >> Hi = Stephen
    >> 
    >> The = client is signing the first request. The key *might* be in the body. The = client is signing all the subsequent requests as well. The "access = token" is not needed by the client to prove it is authorized as the = client is proving it is the same client again.
    >> 
    >> In = other words, I don't see the need for an access token, so it does not = need to be put in a URL or an auth header.
    >> 
    >> If = a developer really, really wants to hand context back to the client for = subsequent calls, they can put it in the URL or some other method. = Putting it in the HTTP Authorization header is confusing because it is = NOT an access token -- it is the context of the request.
    >> 
    >> =E1=90=A7
    >> 
    >> On = Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even = though I've only been lightly following things, I feel the need to voice = my preference as a developer since I will probably someday have to = either write a RC or RS... 
    >> 
    >> The = way I see it is the RC makes the initial request to the AS as part of = this request, it provides it's key in the body... (So no use of the = Authorization header)
    >> At this point that request, = represented by the continue URL + "Access Token", from my lazy developer = standpoint, is a Resource Endpoint and Access Token, and the AS is = acting as a specialized RS in this case.
    >> So my = client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a = token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client.
    >> Personally I like that, because if I have = an access_token, I already think "Put it in the auth header." 
    >> 
    >> So = my vote would be +1 for the pull request at this time.
    >> -steve
    >> 
    >> On = Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
    >> = inline ... 
    >> 
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others = had already responded to this previous thread, but I wanted to add a = couple points to clarify some things.
    >> 
    >>> = 3) What the client has to do with the "access token" is not the same as = access tokens for an RS. The client gets a new "access token" for each = grant request, and for each API call to the AS, and the client learns it = can not make any more API calls for that specific request when it does = not get an "access token" back. This is a completely different design = pattern than calling an RS API with an access token, and is a new design = pattern for calling APIs. This adds complexity to the client that it = would not normally have, and I don't think GNAP is the right place to = start a new design pattern.
    >>> 
    >> 
    >> = I=E2=80=99m not sure what you mean by these being different =E2=80=94 = the whole point of the design is that the client would be doing the same = thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical.
    >> 
    >> The = client is getting the "access token" from its API. It is not using an = "access_token" in other API calls to the AS.
    >>  
    >> 
    >> = Rotation of the access token and artifacts for ongoing continuation = responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87
    >> 
    >> And = for what it=E2=80=99s worth, GNAP is absolutely the right place to have = new designs =E2=80=94 not that this is one.
    >> 
    >> You = are proposing a new way for an API to provide context for subsequent API = calls. Looks out of scope to me.
    >>  
    >> 
    >>> = 4) Clients that only want claims from the AS and no access tokens will = be required to support an API calling mechanism they would not have to = support otherwise. 
    >> 
    >> Correct, but the delta between the calls a client = would make with and without an access token is vanishingly small. The = client has to sign the initial request in some fashion, and it will sign = the continuation request in the same exact fashion, but now include an = access token in that request. 
    >> 
    >> Per = my other point, there is no value to me in my implementations of passing = context back and forth between the client and AS -- so it is extra work = providing no value.
    >> 
    >> = Also, any client authentication mechanism that wants to use the HTTP = Authentication header is precluded from using it.
    >> 
    >>  
    >> 
    >> = Clients making a request to an AS and not getting an access token is a = new design pattern. I think it has value and should be included, but = OAuth today shows us the immense value of getting access tokens for = calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern.
    >> 
    >>> 
    >>> = 5) If the AS does not provide an "access token", there is no mechanism = for a client to delete the request, as the client is not allowed to make = a call without an "access token".
    >> 
    >> = More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D = field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field.
    >> 
    >> There is nuance in that intention. A related concern = is that deleting a request does not seem like it is a "continue" = operation.
    >>  
    >> 
    >>> 
    >>> = 6) There is no standard identifier for the request. Debugging and = auditing are hampered by the client and AS having no standard way to = identifying a request. While one AS may provide a unique URL for each = grant request, another AS may use a persistent "access token" to = identify the grant request, and other ASs may issue a new "access token" = on each API call, providing no persistent identifier for the request.
    >> 
    >> Debugging and auditing this kind of thing are = functions of the AS. How is interoperability harmed by different ASs = having different methods to identify their internal data elements? The = client doesn=E2=80=99t need any knowledge of the AS=E2=80=99s = identifiers, it just needs to know the next steps for continuing the = negotiation.
    >> 
    >> = Debugging between the client and the AS was what I was referring to. How = does a client developer identify the request when communicating to the = AS developer. Seems complicated.
    >>  
    >> = =E1=90=A7
    >> -- 
    >> = TXAuth mailing list
    >>     TXAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> -- 
    >> = TXAuth mailing list
    >> TXAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> -- 
    >> = TXAuth mailing list
    >> TXAuth@ietf.org
    >> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3D= AOvVaw0r39lH4qVOu0IQPJJYtSpI

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


    -- 
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th = Floor, 10 Temple = Back, Bristol, BS1 6FL
    t: +44 (0)117 280 5120

    Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360)= at https://register.fca.org.uk/. = Moneyhub Financial Technology is registered in England & = Wales, company registration number  06909772 .
    Moneyhub Financial Technology = Limited 2019 =C2=A9

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

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

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




    -- 
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th = Floor, 10 Temple = Back, Bristol, BS1 6FL
    t: +44 (0)117 280 5120

    Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360)= at https://register.fca.org.uk/. = Moneyhub Financial Technology is registered in England & = Wales, company registration number  06909772 .
    Moneyhub Financial Technology = Limited 2019 =C2=A9

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

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

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



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


    -- 
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th = Floor, 10 Temple = Back, Bristol, BS1 6FL
    t: +44 (0)117 280 5120

    Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360)= at https://register.fca.org.uk/. = Moneyhub Financial Technology is registered in England & = Wales, company registration number  06909772 .
    Moneyhub Financial Technology = Limited 2019 =C2=A9

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

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

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





    -- 
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th = Floor, 10 Temple = Back, Bristol, BS1 6FL
    t: +44 (0)117 280 5120

    Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited = which is authorised and regulated by the Financial Conduct Authority = ("FCA"). Moneyhub Financial Technology is entered on the Financial = Services Register (FRN 809360)= at https://register.fca.org.uk/. = Moneyhub Financial Technology is registered in England & = Wales, company registration number  06909772 .
    Moneyhub Financial Technology = Limited 2019 =C2=A9

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

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

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




    -- 
    Dave = Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th Floor, 10 Temple Back, = Bristol, BS1 6FL
    t: +44 (0)117 280 5120

    Moneyhub Enterprise is a trading = style of Moneyhub Financial Technology Limited which is authorised and = regulated by the Financial Conduct Authority ("FCA"). Moneyhub = Financial Technology is entered on the Financial Services = Register (FRN 809360) = at https://register.fca.org.uk/. = Moneyhub Financial Technology is registered in England & = Wales, company registration number  06909772 .
    Moneyhub Financial Technology = Limited 2019 =C2=A9

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

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

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


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

    = --Apple-Mail=_7CC6F77E-E7A0-4592-8B0A-3346936EACD2-- From nobody Wed Dec 16 08:47:08 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC193A0E29; Wed, 16 Dec 2020 08:47:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160813722285.2857.1050189981211833742@ietfa.amsl.com> Date: Wed, 16 Dec 2020 08:47:02 -0800 Archived-At: Subject: [GNAP] Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-01-12 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, 16 Dec 2020 16:47:03 -0000 The Grant Negotiation and Authorization Protocol (gnap) WG will hold a virtual interim meeting on 2021-01-12 from 19:00 to 20:30 Asia/Jerusalem (17:00 to 18:30 UTC). Agenda: Core protocol open issues, details TBD. Information about remote participation: https://intuit.zoom.us/j/99533101832?from=addon From nobody Wed Dec 16 09:53:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86E3A08AB for ; Wed, 16 Dec 2020 09:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Q5vUelhgxdzX for ; Wed, 16 Dec 2020 09:53:07 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10883A07EA for ; Wed, 16 Dec 2020 09:53:06 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id k8so23368166ilr.4 for ; Wed, 16 Dec 2020 09:53:06 -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=ZCwNa9+SWCUeJfYzb+ScMpbv5Dia2hSVMaBkE6Ka4sU=; b=Tj0ppLKb7f7ulReXlTSdDxQQMun42RtkcoRNQnUe/geQkV4cdh85xwwzYSfW2MIkaS J3K2Z+QmQG0TCoC/UKPzxQa9Xf2LE5qmTzBAR4pmFq2KUmnmReOMjdxk+70qSBFS6hwD FRlon1g4Nl8jl/7bkkkphjTbt3YNQaQORip5w7ChG2g6L7P8oMA/q6VaiflBKif87wyc F0JJopmnyVx5OE2r/1PQQudijGnIrEzHMKkHfsknDy3lbzQuNg8zo9mwiqu0m83q8MIl behN+VdeDLQsf75eznYw+N2T1KDNsrjxrvFVdz2Nq2IQu+8ls3P9EWKyJ7c2DGI704Gb SKVw== 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=ZCwNa9+SWCUeJfYzb+ScMpbv5Dia2hSVMaBkE6Ka4sU=; b=jMWpv/a2fCqaC7530A1+ubCpgFeb7oN/bWxzur14478deSXPc7VD6ITVSxijPGx7Fh 9S94jy9ettBUG/hOBgHyyTM5ox1llzoAiZBg6XrjAlijkuEk1Xc/qNPwy4AoB9pQnoza OlHUc0B8lyLWSnfW6PVTPHJbN9bQB1ZQWocm8huIGcYXXIbVFXP/8rluN5A3tUvBMHHr Z8O6Wk7CQL/F2u0JtvrkmR7Q501AAlvfTWPneto6sVwc5fRWVBHGS1KNgx0euoI3heVW EM8VKUkZoMPSGr0LG5U0/qT8xk+zV2KuRlxTWZ6kGJGK+lZv96GEboqA7GcgxqgZN8NF /c2w== X-Gm-Message-State: AOAM530AtLCQhs+h6LiuywlotPHylZ5MumUHDNPbKqfGjtAiTNPJkoax ar/nw0QhPY+1xvdMWqTGbYCld2VgeL/7X7kN X-Google-Smtp-Source: ABdhPJwFeG3KHct23c/7bBYlG/8hm5n5YoAEhLhZ8j0X/uuxnxEYlKt57VW/WX2KyV4cWCgiprBG5g== X-Received: by 2002:a92:204:: with SMTP id 4mr47898530ilc.79.1608141184947; Wed, 16 Dec 2020 09:53:04 -0800 (PST) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id t18sm1546814ils.16.2020.12.16.09.53.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Dec 2020 09:53:02 -0800 (PST) Received: by mail-io1-f45.google.com with SMTP id 81so24740964ioc.13 for ; Wed, 16 Dec 2020 09:53:02 -0800 (PST) X-Received: by 2002:a5d:970c:: with SMTP id h12mr17871293iol.103.1608141182000; Wed, 16 Dec 2020 09:53:02 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> <9CA7546C-9A07-4F2D-9A1F-4755BDD3D1C9@mit.edu> In-Reply-To: <9CA7546C-9A07-4F2D-9A1F-4755BDD3D1C9@mit.edu> From: Aaron Parecki Date: Wed, 16 Dec 2020 09:52:50 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: Warren Parad , Dave Tonge , txauth gnap , Steve Moore , Fabien Imbault , Torsten Lodderstedt , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000e6eecd05b6988b16" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 16 Dec 2020 17:53:15 -0000 --000000000000e6eecd05b6988b16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This has been a great discussion, and we've opened three new issues to track things that came up in this thread that follow on from the changes in the PR: * persistent grant identifier https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146 * rotation of tokens related to continuation request https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147 * special label for access token used for continuation https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149 The editors believe the specifics in this PR have rough consensus, so we're going ahead with merging it. Aaron On Wed, Dec 16, 2020 at 3:37 AM Justin Richer wrote: > On Dec 16, 2020, at 5:15 AM, Warren Parad wrote: > > > #4 is a prereq for this discussion though. If the token is the identifier > of the grant then it must be in the url to avoid the problem of arbitrary > url construction. Of course the uri would be *https://as/grants/{grantIde= ntifier} > *. And this is actually > independent of whether or not the token gets rotated. > > > That=E2=80=99s not true: the identifier exposed to the client for some pu= rpose > like grant extension doesn=E2=80=99t have to be the same identifier that = the AS > uses for management. The latter is internal, and exposing internal state = to > the protocol shouldn=E2=80=99t be a requirement to the pattern. > > > #3 The idea of a dynamic environment is important here, however the > argument doesn't justify having this being the same endpoint. Nothing sto= ps > us from having two endpoints, one that requests an access token separate > from the ones that manage the grant resource. > > > Nobody said this has to be the same endpoint. In fact, this structure is > being put in place to allow them to be separate endpoints. My original > design in XYZ used a single endpoint and exposed an internal identifier o= f > the ongoing grant request to the client within the protocol (the > transaction handle). Changing this to a properly abstracted and protected > API pattern allows much greater flexibility. The AS now has the choice of > how it wants to manage its own dispatching, without the client needing to > be aware of any of it since the client always does the same thing. > > =E2=80=94 Justin > > > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge > wrote: > >> > Dave: which points changed your mind? >> >> 1. The issue with re-using client authentication across endpoints in the >> OAuth 2 world >> (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods= _supported, introspection_endpoint_auth_methods_supported...) >> >> 2. The clear articulation of the 3 different functions of the AS >> (including the idea of a self-hosted AS) >> >> 3. The aim to support a more dynamic environment where client >> authentication only happens in the first interaction between the RC and = the >> AS >> >> 4. The agreement that there should be further discussion on whether this >> access token should be rotated, and whether it should be an identifier o= f >> the grant. >> >> >> On Wed, 16 Dec 2020 at 00:02, Dick Hardt wrote: >> >>> Dave: which points changed your mind? >>> >>> On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge >>> wrote: >>> >>>> Thanks for the detailed response. >>>> >>>> I think you make the points well and I'm now in favour of the PR. >>>> However I do think that to keep the consistency that keeps being >>>> discussed, that the tokens shouldn't be rotated. >>>> >>>> I also think it would be good to have a discussion about "grant >>>> management" and identifiers for a grant. >>>> >>>> Dave >>>> >>>> On Tue, 15 Dec 2020 at 17:30, Justin Richer wrote: >>>> >>>>> On Dec 15, 2020, at 10:50 AM, Dave Tonge >>>>> wrote: >>>>> >>>>> >>>>> > The access token pattern has a lot of benefits, otherwise we >>>>> wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>>>> >>>>> *But what are the benefits in this particular use case?* The >>>>> continuation API is not like any other API - it is integral to the AS= . >>>>> There are quite a few extensions to OAuth that use client authenticat= ion >>>>> rather than access tokens. >>>>> >>>>> >>>>> Yes, and the propagation of that has lead to a mess in the OAuth >>>>> world. You=E2=80=99ve got re-definitions of client authentications at= all different >>>>> endpoints, they=E2=80=99re technically allowed to vary between endpoi= nts (though I >>>>> don=E2=80=99t know of it happening in practice, that feels like a dow= ngrade attack >>>>> waiting to happen to someone). Then there=E2=80=99s the fact that all= the newest >>>>> security mechanisms we have =E2=80=94 PKCE, DPoP, and MTLS =E2=80=94 = don=E2=80=99t rely on client >>>>> authentication at all to achieve security. All of these work without = the >>>>> client having credentials previously known to the AS, and we already = know >>>>> that GNAP is going to need to live in this more dynamic world. We nee= d to >>>>> think beyond what OAuth 2 has done in the past, and especially from o= ur >>>>> perceptions and assumptions of the models that drive OAuth 2=E2=80=99= s decisions, >>>>> lest we repeat its mistakes. >>>>> >>>>> Also, I want to challenge this idea of =E2=80=9Cintegral to the AS=E2= =80=9D as a >>>>> point. In OAuth 1, the API was =E2=80=9Cintegral=E2=80=9D to the serv= er side, but in OAuth >>>>> 2 we split that into the RS concept. Even though in practice, a lot o= f RS=E2=80=99s >>>>> are still integrated to the AS in some fashion because it=E2=80=99s a= single >>>>> service, OAuth 2 is clear about what=E2=80=99s expected to be known b= y each >>>>> component. For the AS as currently defined in GNAP, I=E2=80=99m seein= g three >>>>> distinct functions. As per the Terminology discussion, we don=E2=80= =99t have >>>>> explicit names for these yet: >>>>> >>>>> - starting a request; this is an endpoint to kick things off; it >>>>> needs to be able to look up the rights asked for by the client (if it= knows >>>>> the client at all ahead of time) and make initial decisions about nee= ded >>>>> interaction and follow up >>>>> - continuing a request; this is an API that needs to know the contex= t >>>>> of the request itself, including which key it=E2=80=99s bound to; thi= s is separate >>>>> from any identity of the client and possibly the user, but an AS >>>>> implementation that has access to those elements can use them >>>>> - interacting with the user; this is front-facing and in OAuth today >>>>> is already deployed as a separate service in some places, we should e= mbrace >>>>> that at the very least (but doing so formally is a separate issue) >>>>> >>>>> Why separate these in this way? There is immense power in having a >>>>> single consistent way to start the process. The =E2=80=9Ccontinuation= API=E2=80=9D gives us >>>>> an HTTP-defined mechanism for managing a request over time, including= the >>>>> simple case of returning information from the front channel, but peop= le >>>>> have already raised the question of non-HTTP and self-hosted AS=E2=80= =99s, which >>>>> would probably want a different kind of continuation API to communica= te to >>>>> the AS. The same thing with separating out the interaction: there are= going >>>>> to be a lot of different ways to handle interaction out there, and no= t all >>>>> of them will be =E2=80=9Cintegral=E2=80=9D to the AS in the way that = a simple >>>>> implementation might do. We=E2=80=99re defining a protocol based stro= ngly on HTTP >>>>> and JSON, but we should structure it in such a way that it can be ext= ended >>>>> and translated elsewhere in a clear way. >>>>> >>>>> This all raises the question: if we can rely on a unique URL for >>>>> redirect-based interaction, why not here? The simple reason is that a= URL >>>>> is the :only: mechanism we have in the front channel for passing >>>>> information, and we need to warn implementors against including sensi= tive >>>>> information in it, and we need to protect it with additional items. W= e have >>>>> access to more than just URLs when we=E2=80=99re dealing with the con= tinuation API, >>>>> and we ought to make use of all of our tools in ways that are consist= ent >>>>> and make sense. >>>>> >>>>> From a previous email the advantages I see are: >>>>> - more data can be encoded in a token than in a uri (this seems more >>>>> of an edge case) >>>>> - it can be an identifier for the grant (I don't agree with this) >>>>> >>>>> >>>>> It allows the parts above to live separately, even if they don=E2=80= =99t HAVE >>>>> to. And it simplifies what we=E2=80=99re asking the client to do by m= aking it >>>>> consistent with other parts of the ecosystem. The AS offering an API >>>>> doesn=E2=80=99t :have: to be different, and OpenID Connect showed us,= with the >>>>> UserInfo Endpoint, that that=E2=80=99s very much the case in practice= . >>>>> >>>>> Having my client code do very similar things in slightly different >>>>> ways is not simpler. >>>>> >>>>> >>>>> Another question I have: *do we envisage granting access tokens to >>>>> the RC that will allow it to manage multiple grants*? >>>>> >>>>> >>>>> I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t= been brought up >>>>> as a use case to date. >>>>> >>>>> >>>>> I also think there will be confusion with the signing being used for >>>>> different things. Maybe it just needs to be called out in the spec th= at: >>>>> >>>>> Request 1: signature =3D client authentication >>>>> Request 2+: signature =3D proof of possession for access token >>>>> >>>>> >>>>> That=E2=80=99s more or less the intent of what=E2=80=99s in the speci= fication right >>>>> now, and why all the signature methods, which are used for both clien= t auth >>>>> and token possession, are all together in section 8 and not separated= by >>>>> use. (With the caveat: it=E2=80=99s only client authentication in th= e first >>>>> request if the AS knows about the client instance ahead of time, whic= h >>>>> isn=E2=80=99t always going to be true.) That all can likely be made c= learer, as is >>>>> always the case with spec text. But you can use the signature methods= with >>>>> and without access tokens, and it only gets used without in an initia= l call >>>>> where you don=E2=80=99t :have: an access token to present. >>>>> >>>>> Separating the different kinds of =E2=80=9Cclient authentication" out= in OAuth >>>>> is the source of some real confusion. Like right now, what happens if= you >>>>> try to combine a client assertion, signed request objects for PAR, an= d DPoP >>>>> proofs, all in a single request? All of these are optional and all of= them >>>>> =E2=80=9Cdo client authentication=E2=80=9D in some arguable fashion. = I=E2=80=99ve worked on several >>>>> systems and implemented these things, and their interplay is really >>>>> confusing to manage and can go sideways really fast. And that=E2=80= =99s just the >>>>> work for a single endpoint, this gets repeated for introspection, >>>>> revocation, CIBA, device, and on. >>>>> >>>>> At the end of the day I=E2=80=99m in favor of giving the client devel= opers a >>>>> very clear set of directions on what they need to do and how they nee= d to >>>>> access things, and treating the continuation as a token-bound API is,= to >>>>> me, the clearest pattern we can offer for this piece. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, 15 Dec 2020 at 15:33, Justin Richer wrote: >>>>> >>>>>> I agree with Fabien that the persistent identifier is a separate >>>>>> issue. The current spec re-uses the access token for this artifact, = but >>>>>> that=E2=80=99s potentially brittle and could be changed out for some= thing else. >>>>>> There=E2=80=99s an issue asking for expanding on the use cases for t= his >>>>>> functionality (which hasn=E2=80=99t been addressed by this PR): >>>>>> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >>>>>> A potentially-rotating URI would be just as brittle, and so having a >>>>>> single codified identifier for this artifact would be useful, but it= does >>>>>> assume some things about the nature of the AS. Every other use the c= lient >>>>>> has to manage the ongoing request over time doesn=E2=80=99t need an = explicit >>>>>> identifier. Just like with OAuth-protected APIs, the server can dete= rmine >>>>>> the context not just from the URI but from the rest of the request, >>>>>> including the access token itself. This is both more common and more >>>>>> powerful than a strict reading of REST designs. It also follows the = HATEOS >>>>>> principles as the entire HTTP request is taken into account, includi= ng the >>>>>> access token and signature portions. >>>>>> >>>>>> I=E2=80=99ll also point out that the rotation of these credentials i= s also >>>>>> filed as a separate issue that=E2=80=99s not being addressed right n= ow, so we can >>>>>> revisit that discussion separately: >>>>>> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >>>>>> As for the name, we could give it a different label. We have this >>>>>> same pattern of issuing a resource-specific access token alongside a= URL in >>>>>> the Dynamic Registration specification, both in OAuth ( >>>>>> https://tools.ietf.org/html/rfc7592#section-3) and OpenID Connect ( >>>>>> https://openid.net/specs/openid-connect-registration-1_0.html#Regist= rationResponse). >>>>>> Here it=E2=80=99s called the =E2=80=9Cregistration access token=E2= =80=9D =E2=80=94 but what=E2=80=99s important >>>>>> there, as it is here, is that it=E2=80=99s not a different kind of a= rtifact that >>>>>> the client now has to figure out how to use, it=E2=80=99s an access = token plain and >>>>>> simple. In the OAuth world this is a bearer token, since that=E2=80= =99s what OAuth >>>>>> 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2= =80=99s what we=E2=80=99re >>>>>> looking to build on. This is also related to another future discussi= on >>>>>> about responses tying an access token to a specific API that=E2=80= =99s told to the >>>>>> client, as we could potentially re-use those components and concepts= here >>>>>> as well: >>>>>> >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 >>>>>> >>>>>> And finally, no speculation on the complexity is needed: I >>>>>> implemented this pattern several months ago during the design team >>>>>> discussions when we were considering this pattern, and the code is a= ll >>>>>> online for people to see. >>>>>> >>>>>> https://github.com/bspk/oauth.xyz-java/ >>>>>> >>>>>> On the AS side, the most interesting code to this discussion is in >>>>>> the TransactionEndpoint class: >>>>>> >>>>>> >>>>>> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/= io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java >>>>>> >>>>>> Here, you=E2=80=99ll see that on initial request, the server looks u= p the >>>>>> client to see if it=E2=80=99s been registered, but after that, it ma= kes sure that >>>>>> the token and key are appropriate for the ongoing request. From the = client >>>>>> side it=E2=80=99s even simpler. The client=E2=80=99s got a small ser= vice function to manage >>>>>> the different signature methods that are implemented, and all of the= m can >>>>>> take in an optional access token: >>>>>> >>>>>> >>>>>> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/= io/bspk/oauth/xyz/http/SigningRestTemplateService.java >>>>>> >>>>>> The heavy lift is doing the actual signing, and you need that in >>>>>> order to start the process anyway. Managing the access token as an a= rtifact >>>>>> to use at the API is completely trivial since the client already nee= ds to >>>>>> manage its own state internally to do any of this. And note that all= of >>>>>> this is changed from how it was before: Previously, the XYZ Protocol= had >>>>>> used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that = the client would use to >>>>>> continue the request. However, this simple model was limiting, and t= he >>>>>> design team adopted XAuth=E2=80=99s model of continuation being an A= PI. In doing >>>>>> so, we made it like all of the other APIs the client is going to cal= l: in >>>>>> the initial state, it doesn=E2=80=99t have any kind of access rights= , it=E2=80=99s just >>>>>> calling. From that initial call forward, the AS just needs to know t= hat the >>>>>> token and key match what it expects. >>>>>> >>>>>> In summary, my views are: >>>>>> - The access token pattern has a lot of benefits, otherwise we >>>>>> wouldn=E2=80=99t have an entire OAuth ecosystem based on it >>>>>> - Magic URIs have a lot of drawbacks which are well understood; >>>>>> while they can be mitigated, they can also be avoided >>>>>> - Continuation is an API, and treating it like the other kinds of >>>>>> API the client would call makes sense >>>>>> - Calling this by a special name, like =E2=80=9Cgrant access token= =E2=80=9D or >>>>>> =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should f= unction like any other >>>>>> access token >>>>>> - The heavy lift for clients is on protecting the message >>>>>> cryptographically, which they need to do anyway >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> >>>>>> On Dec 15, 2020, at 7:50 AM, Dave Tonge >>>>>> wrote: >>>>>> >>>>>> The persistent identifier is not a different issue, the current >>>>>> access token is used to reference an existing grant >>>>>> >>>>>> >>>>>> >>>>>> It may not be more difficult for a client to *use* an access token >>>>>> at the AS / RS. But there is definitely an overhead on the client to >>>>>> *manage* this separate access token. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >>>>>>> I think we always said the access token was different, and handled >>>>>>> as a bound token. >>>>>>> >>>>>>> But it doesn't mean it's more difficult for the client that already >>>>>>> needs to be able to handle tokens anyway (bearer or not, both cases= could >>>>>>> occur). It's mostly consolidating the logic. >>>>>>> >>>>>>> You're anticipating a lot of issues which have no specific reason t= o >>>>>>> occur, such as "can't be used with the token management APIs?". The >>>>>>> management API is part of the same general flow. >>>>>>> Anticipating issues with rotation is useful, but there are also man= y >>>>>>> ways it can be hard to manage through a stateful approach too. And >>>>>>> fundamentally, having everything in a common model (both for the in= ternals >>>>>>> of the AS and for the API calls) will help improve by a large margi= n what >>>>>>> is probably the weakest point in today's infrastructure. But it's e= arly to >>>>>>> be definitive as to the downstream impact either way. >>>>>>> >>>>>>> As for a persistent identifier instead of a continuation API, and >>>>>>> generally the end of your message, it's a totally unrelated issue t= o this >>>>>>> PR, so I suggest we don't discuss that here, but in a separate issu= e if >>>>>>> needed. >>>>>>> >>>>>>> Fabien >>>>>>> >>>>>>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>>>>>> wrote: >>>>>>> >>>>>>>> So we've established that this is a different access token, that >>>>>>>> requires different handling at the client. So keeping it could cau= se more >>>>>>>> confusion? >>>>>>>> >>>>>>>> As an RC, I will have to store the continue `uri` as although it >>>>>>>> could be static it could also be dynamic. Why do I need to store a= n access >>>>>>>> token as well. It brings me no benefit as an RC, in fact it brings= more >>>>>>>> complexity. As I will now need to manage multiple types of tokens = with >>>>>>>> different lifecycles: >>>>>>>> >>>>>>>> *Continuation token* >>>>>>>> - can only be used at the continue endpoint (the name of which i= s >>>>>>>> confusing as I can use this endpoint to revoke a grant or get meta= data on >>>>>>>> the grant). >>>>>>>> - may be rotated each time it is used, or may not be >>>>>>>> - provided in the `continue` section of the response >>>>>>>> - must be sender-constrained >>>>>>>> - can't be used with the token management APIs? >>>>>>>> - can be used to identify the grant when making subsequent grants >>>>>>>> >>>>>>>> *Access token(s) to use at RS* >>>>>>>> - can only be used at the specified RS >>>>>>>> - may be sender constrained >>>>>>>> - when used at the RS, will not result in rotation >>>>>>>> >>>>>>>> From my perspective, most use-cases will require the RC to have a >>>>>>>> persistent identifier for the grant. Why not bring this into the p= rotocol >>>>>>>> and let the AS provide this persistent identifier (through the for= m of the >>>>>>>> continue uri). Using a rotating access token as a persistent ident= ifier >>>>>>>> doesn't seem like the right choice. >>>>>>>> >>>>>>>> I see no security benefit to having the continuation access token. >>>>>>>> It doesn't matter if the continue uri leaks as it is useless witho= ut an >>>>>>>> accompanying signature, i.e. any security benefit of having an acc= ess token >>>>>>>> is already provided by having a signature. >>>>>>>> >>>>>>>> The only benefits that I can see are: >>>>>>>> - If the AS wants to be fully stateless, then you can encode more >>>>>>>> data in a token than in a uri >>>>>>>> - If the AS wants to have a static endpoint for CRUD operations o= n >>>>>>>> the grant >>>>>>>> - To allow the AS to identity a previous grant >>>>>>>> >>>>>>>> If we dropped the access token for the continue endpoint and rathe= r >>>>>>>> mandated a dynamic uri this would make things conceptually easier = to >>>>>>>> understand, easier for the RC to implement, easier to debug and le= ss chance >>>>>>>> of errors when rotating tokens (i.e. race conditions could be quit= e likely >>>>>>>> if the AS always rotates the token) >>>>>>>> >>>>>>>> *One-off grant with no continuation or ongoing management:* >>>>>>>> RC sends signature and metadata, no `continue` response provided, >>>>>>>> therefore no grant management possible >>>>>>>> >>>>>>>> *Grant with ongoing management* >>>>>>>> RC sends signature and metadata, AS responds with a continue uri >>>>>>>> that has these purposes: >>>>>>>> - can be used by the RC to continue/update, read or revoke the >>>>>>>> grant >>>>>>>> - can be used by the RC when making a new grant to identify the >>>>>>>> previous grant >>>>>>>> >>>>>>>> As an RC the only permanent items I need to store are: >>>>>>>> - the continue uri associated with the grant >>>>>>>> - any access tokens I receive for the grant >>>>>>>> >>>>>>>> Dave >>>>>>>> >>>>>>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault < >>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Torsten, >>>>>>>>> >>>>>>>>> You're right on both accounts. >>>>>>>>> - for the first remark, it fits quite nicely the init request / >>>>>>>>> continuation pattern >>>>>>>>> - for the second remark, it is a sort of handle for the >>>>>>>>> continuation request, which will eventually lead to the issuance = or refresh >>>>>>>>> of standard access tokens >>>>>>>>> >>>>>>>>> Having a specific name is a possibility, I actually suggested tha= t >>>>>>>>> too at some point. >>>>>>>>> >>>>>>>>> Fabien >>>>>>>>> >>>>>>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>>>>>> torsten@lodderstedt.net> wrote: >>>>>>>>> >>>>>>>>>> Hi Fabien, >>>>>>>>>> >>>>>>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com>: >>>>>>>>>> > >>>>>>>>>> > Hi, >>>>>>>>>> > >>>>>>>>>> > On the contrary your feedback is most welcome. >>>>>>>>>> > >>>>>>>>>> > It doesn't accept any token, it needs the particular token as >>>>>>>>>> described in 3.1 and which is not a bearer token (that's what th= e "key" : >>>>>>>>>> true parameter is supposed to convey). >>>>>>>>>> > >>>>>>>>>> > Let us know if you need more clarifications. >>>>>>>>>> >>>>>>>>>> Thanks for the clarification. I think only accepting this kind o= f >>>>>>>>>> token at the continuation is a good idea otherwise the AS would = need to be >>>>>>>>>> able to parse and understand all sorts of access tokens. >>>>>>>>>> >>>>>>>>>> Conceptually, I like the idea to treat the continuation as >>>>>>>>>> another kind of resource. However, here are some observations I = want to >>>>>>>>>> share with you: >>>>>>>>>> - This resource is different as it will issue other access token= s >>>>>>>>>> (of this kind) to be used in subsequent continuation requests. T= his >>>>>>>>>> requires different handing on the client side. >>>>>>>>>> - This access token (if I understand correctly) is (or at least >>>>>>>>>> feels like) a handle for the underlying grant. So it is kind of = the super >>>>>>>>>> access token to obtain other access tokens. >>>>>>>>>> >>>>>>>>>> I would consider using a different term to refer to this special >>>>>>>>>> access token, grant token or grant handle for example, in order = to prevent >>>>>>>>>> confusion. >>>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> Torsten. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > Best >>>>>>>>>> > Fabien >>>>>>>>>> > >>>>>>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>>>>>> > Hi all, >>>>>>>>>> > >>>>>>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me que= stion >>>>>>>>>> seems naive. >>>>>>>>>> > >>>>>>>>>> > After having skimmed through the current draft and the PR, I= =E2=80=98m >>>>>>>>>> not sure whether the continuation requests accepts any access to= ken issued >>>>>>>>>> to the RC or the particular access token returned in the =E2=80= =9Econtinue=E2=80=9C element >>>>>>>>>> in section 3.1.. >>>>>>>>>> > >>>>>>>>>> > Can you please shed some light on this? >>>>>>>>>> > >>>>>>>>>> > kind regards, >>>>>>>>>> > Torsten. >>>>>>>>>> > >>>>>>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com>: >>>>>>>>>> >> >>>>>>>>>> >> =EF=BB=BF >>>>>>>>>> >> You're completely right. Allowing the dev to be lazy is a ver= y >>>>>>>>>> good thing in general, because it's what we know will work :-) >>>>>>>>>> >> >>>>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore >>>>>>>>>> a =C3=A9crit : >>>>>>>>>> >> Hi Fabien, >>>>>>>>>> >> >>>>>>>>>> >> For #3) Even after I typed out the hypothetical attack, that >>>>>>>>>> was sort of in the back of my mind, it isn't a huge risk there. = So I >>>>>>>>>> actually agree with Dick there. Something doesn't sit right with= me for the >>>>>>>>>> unique URL solution, so I don't like it and came up with a hypot= hetical >>>>>>>>>> that seems like it could be a down side. >>>>>>>>>> >> >>>>>>>>>> >> I still think the access token model with the signed request >>>>>>>>>> is the way I'd like to go, because again, it's a mechanism I'd b= e >>>>>>>>>> implementing anyway to talk to any 'normal' resource. The fact i= s there is >>>>>>>>>> _something_ representing context that has to pass back and forth= here, >>>>>>>>>> whether that is an access token (which I feel like is more flexi= ble for >>>>>>>>>> extensions etc), a unique url, or even a cookie sent in the cook= ie header. >>>>>>>>>> So just to re-iterate, I'm a +1 on this pull request, speaking a= s a lazy >>>>>>>>>> developer ;) >>>>>>>>>> >> -steve >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>>>>> >> Again speaking in my own name here. >>>>>>>>>> >> >>>>>>>>>> >> Dick, we know you'd prefer to have a different design, but >>>>>>>>>> this PR shouldn't be about that. >>>>>>>>>> >> >>>>>>>>>> >> Back on your 3 items : >>>>>>>>>> >> >>>>>>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>>>>>> decided that wouldn't be how that would work. We have a client i= nstance >>>>>>>>>> that allows a more generic and flexible pattern (which BTW also = allows what >>>>>>>>>> you want) >>>>>>>>>> >> >>>>>>>>>> >> 2) instead of blame arguments of who's less >>>>>>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversa= tions, I >>>>>>>>>> suggest we speak in less abstract terms and ask ourselves what t= hat means >>>>>>>>>> in practice for devs. Stephen and several others (myself include= d) have >>>>>>>>>> expressed that it wouldn't be harder to implement, it would even= simplify >>>>>>>>>> things quite a lot. If you disagree please send us a code sample= to really >>>>>>>>>> show that point by example, because that's really not obvious. >>>>>>>>>> >> >>>>>>>>>> >> 3) "If someone has the client credentials, they can >>>>>>>>>> impersonate the client, and all bets are off." Are you seriously= making >>>>>>>>>> this argument? Because if you have a better proposal than using >>>>>>>>>> cryptographic keys, I'm all hears. You make it look like there's= a problem, >>>>>>>>>> while in reality we're only relying on the basic assumption of a= ll modern >>>>>>>>>> digital communications. >>>>>>>>>> >> >>>>>>>>>> >> And more importantly you never responded to the issues of how >>>>>>>>>> to avoid the security pitfalls of what you proposed. >>>>>>>>>> >> >>>>>>>>>> >> Fabien >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt >>>>>>>>>> a =C3=A9crit : >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore < >>>>>>>>>> srmoore@gmail.com> wrote: >>>>>>>>>> >> But from the spec: >>>>>>>>>> >> " >>>>>>>>>> >> When sending a non-continuation request to the AS, the RC MUS= T >>>>>>>>>> identify itself by including the client field of the request... >>>>>>>>>> >> ... >>>>>>>>>> >> key (object / string) : The public key of the RC to be used i= n >>>>>>>>>> this request as described in {{request-key}}. This field is REQU= IRED. >>>>>>>>>> >>>>>>>>>> >> ... >>>>>>>>>> >> " >>>>>>>>>> >> So on the initial request, the key will be there. >>>>>>>>>> >> >>>>>>>>>> >> The client field can be an object or a string. If the client >>>>>>>>>> is pre-registered, then a string could be provided instead of an= object. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> If you don't have the access token, then how do you >>>>>>>>>> differentiate between two requests from the same web application= by two >>>>>>>>>> different users? Is the web application supposed to have differe= nt >>>>>>>>>> credentials for every request? >>>>>>>>>> >> >>>>>>>>>> >> The AS returns a URI for manipulating the request. I would >>>>>>>>>> change the spec so that each request would have a unique URI. Th= is is the >>>>>>>>>> usually RESTful pattern that the resource (the grant request) ha= s an URI. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> So in this case, the easy way out is to pass the access token >>>>>>>>>> to the client, who then, as i stated before, treats the continue= request as >>>>>>>>>> a RS call (albeit a specialized version of the RS where the RS i= s the AS) >>>>>>>>>> OR to use the unique URL, >>>>>>>>>> >> but that seems open to a brute force attack by a malicious RC= . >>>>>>>>>> (What would be the point of that attack, I don't know, I guess i= f someone >>>>>>>>>> had the client credentials but not any subjects/resources they c= ould try to >>>>>>>>>> intercept the grant via continue... I just don't feel right lock= ing things >>>>>>>>>> down to unique URLs that way.) >>>>>>>>>> >> >>>>>>>>>> >> If someone has the client credentials, they can impersonate >>>>>>>>>> the client, and all bets are off. >>>>>>>>>> >> >>>>>>>>>> >> LOTS of RS servers return a resource specific URL -- my >>>>>>>>>> proposal is no different. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> -steve >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt < >>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>> >> Hi Stephen >>>>>>>>>> >> >>>>>>>>>> >> The client is signing the first request. The key *might* be i= n >>>>>>>>>> the body. The client is signing all the subsequent requests as w= ell. The >>>>>>>>>> "access token" is not needed by the client to prove it is author= ized as the >>>>>>>>>> client is proving it is the same client again. >>>>>>>>>> >> >>>>>>>>>> >> In other words, I don't see the need for an access token, so >>>>>>>>>> it does not need to be put in a URL or an auth header. >>>>>>>>>> >> >>>>>>>>>> >> If a developer really, really wants to hand context back to >>>>>>>>>> the client for subsequent calls, they can put it in the URL or s= ome other >>>>>>>>>> method. Putting it in the HTTP Authorization header is confusing= because it >>>>>>>>>> is NOT an access token -- it is the context of the request. >>>>>>>>>> >> >>>>>>>>>> >> =E1=90=A7 >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore < >>>>>>>>>> srmoore@gmail.com> wrote: >>>>>>>>>> >> Even though I've only been lightly following things, I feel >>>>>>>>>> the need to voice my preference as a developer since I will prob= ably >>>>>>>>>> someday have to either write a RC or RS... >>>>>>>>>> >> >>>>>>>>>> >> The way I see it is the RC makes the initial request to the A= S >>>>>>>>>> as part of this request, it provides it's key in the body... (So= no use of >>>>>>>>>> the Authorization header) >>>>>>>>>> >> At this point that request, represented by the continue URL + >>>>>>>>>> "Access Token", from my lazy developer standpoint, is a Resource= Endpoint >>>>>>>>>> and Access Token, and the AS is acting as a specialized RS in th= is case. >>>>>>>>>> >> So my client posts to whatever URL with the 'access token' in >>>>>>>>>> the authorization header, just like acting on any other resource= I have a >>>>>>>>>> token for. YES, I get a new token value to use every call, and t= here is a >>>>>>>>>> decision point of "Do I have another continue, or do I have a re= al token >>>>>>>>>> for the resource..." But the mechanism is the same to me in the = client. >>>>>>>>>> >> Personally I like that, because if I have an access_token, I >>>>>>>>>> already think "Put it in the auth header." >>>>>>>>>> >> >>>>>>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>>>>>> >> -steve >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt < >>>>>>>>>> dick.hardt@gmail.com> wrote: >>>>>>>>>> >> inline ... >>>>>>>>>> >> >>>>>>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>>>>> wrote: >>>>>>>>>> >> Others had already responded to this previous thread, but I >>>>>>>>>> wanted to add a couple points to clarify some things. >>>>>>>>>> >> >>>>>>>>>> >>> 3) What the client has to do with the "access token" is not >>>>>>>>>> the same as access tokens for an RS. The client gets a new "acce= ss token" >>>>>>>>>> for each grant request, and for each API call to the AS, and the= client >>>>>>>>>> learns it can not make any more API calls for that specific requ= est when it >>>>>>>>>> does not get an "access token" back. This is a completely differ= ent design >>>>>>>>>> pattern than calling an RS API with an access token, and is a ne= w design >>>>>>>>>> pattern for calling APIs. This adds complexity to the client tha= t it would >>>>>>>>>> not normally have, and I don't think GNAP is the right place to = start a new >>>>>>>>>> design pattern. >>>>>>>>>> >>> >>>>>>>>>> >> >>>>>>>>>> >> I=E2=80=99m not sure what you mean by these being different = =E2=80=94 the >>>>>>>>>> whole point of the design is that the client would be doing the = same thing >>>>>>>>>> with the access token at the AS that it does with the RS by re-u= sing the >>>>>>>>>> access token structure. Can you please describe what the differe= nces are, >>>>>>>>>> apart from the rotation? Presentation of the token and signing o= f the >>>>>>>>>> message are identical. >>>>>>>>>> >> >>>>>>>>>> >> The client is getting the "access token" from its API. It is >>>>>>>>>> not using an "access_token" in other API calls to the AS. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>>>>>> continuation responses is a separate issue to be discussed: >>>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>>>>> >> >>>>>>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right= place to >>>>>>>>>> have new designs =E2=80=94 not that this is one. >>>>>>>>>> >> >>>>>>>>>> >> You are proposing a new way for an API to provide context for >>>>>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >>> 4) Clients that only want claims from the AS and no access >>>>>>>>>> tokens will be required to support an API calling mechanism they= would not >>>>>>>>>> have to support otherwise. >>>>>>>>>> >> >>>>>>>>>> >> Correct, but the delta between the calls a client would make >>>>>>>>>> with and without an access token is vanishingly small. The clien= t has to >>>>>>>>>> sign the initial request in some fashion, and it will sign the c= ontinuation >>>>>>>>>> request in the same exact fashion, but now include an access tok= en in that >>>>>>>>>> request. >>>>>>>>>> >> >>>>>>>>>> >> Per my other point, there is no value to me in my >>>>>>>>>> implementations of passing context back and forth between the cl= ient and AS >>>>>>>>>> -- so it is extra work providing no value. >>>>>>>>>> >> >>>>>>>>>> >> Also, any client authentication mechanism that wants to use >>>>>>>>>> the HTTP Authentication header is precluded from using it. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> Clients making a request to an AS and not getting an access >>>>>>>>>> token is a new design pattern. I think it has value and should b= e included, >>>>>>>>>> but OAuth today shows us the immense value of getting access tok= ens for >>>>>>>>>> calling APIs, and so we shouldn=E2=80=99t optimize away from tha= t pattern. >>>>>>>>>> >> >>>>>>>>>> >>> >>>>>>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>>>>>> mechanism for a client to delete the request, as the client is n= ot allowed >>>>>>>>>> to make a call without an "access token". >>>>>>>>>> >> >>>>>>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue= =E2=80=9D field >>>>>>>>>> then the client can=E2=80=99t delete the request =E2=80=94 and y= es, that=E2=80=99s intentional. The >>>>>>>>>> AS is telling this client instance that it can=E2=80=99t do anyt= hing else with this >>>>>>>>>> ongoing request. If the AS wants to allow the client to manage i= t, it will >>>>>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80= =9D field. >>>>>>>>>> >> >>>>>>>>>> >> There is nuance in that intention. A related concern is that >>>>>>>>>> deleting a request does not seem like it is a "continue" operati= on. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >>> >>>>>>>>>> >>> 6) There is no standard identifier for the request. Debuggin= g >>>>>>>>>> and auditing are hampered by the client and AS having no standar= d way to >>>>>>>>>> identifying a request. While one AS may provide a unique URL for= each grant >>>>>>>>>> request, another AS may use a persistent "access token" to ident= ify the >>>>>>>>>> grant request, and other ASs may issue a new "access token" on e= ach API >>>>>>>>>> call, providing no persistent identifier for the request. >>>>>>>>>> >> >>>>>>>>>> >> Debugging and auditing this kind of thing are functions of th= e >>>>>>>>>> AS. How is interoperability harmed by different ASs having diffe= rent >>>>>>>>>> methods to identify their internal data elements? The client doe= sn=E2=80=99t need >>>>>>>>>> any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps >>>>>>>>>> for continuing the negotiation. >>>>>>>>>> >> >>>>>>>>>> >> Debugging between the client and the AS was what I was >>>>>>>>>> referring to. How does a client developer identify the request w= hen >>>>>>>>>> communicating to the AS developer. Seems complicated. >>>>>>>>>> >> >>>>>>>>>> >> =E1=90=A7 >>>>>>>>>> >> -- >>>>>>>>>> >> TXAuth mailing list >>>>>>>>>> >> TXAuth@ietf.org >>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >> =E1=90=A7 >>>>>>>>>> >> -- >>>>>>>>>> >> TXAuth mailing list >>>>>>>>>> >> TXAuth@ietf.org >>>>>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>>> >> -- >>>>>>>>>> >> TXAuth mailing list >>>>>>>>>> >> TXAuth@ietf.org >>>>>>>>>> >> >>>>>>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/list= info/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> TXAuth mailing list >>>>>>>>> TXAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dave Tonge >>>>>>>> CTO >>>>>>>> [image: Moneyhub Enterprise] >>>>>>>> >>>>>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>>>>> BS1 6FL >>>>>>>> >>>>>>>> t: +44 (0)117 280 5120 >>>>>>>> >>>>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>>>> Technology Limited which is authorised and regulated by the Financ= ial >>>>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entere= d on the >>>>>>>> Financial Services Register (FRN 809360) at *https://register.fca.= org.uk/ >>>>>>>> *. Moneyhub Financial Technology is >>>>>>>> registered in England & Wales, company registration number >>>>>>>> 06909772 . >>>>>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>>>>> >>>>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>>>> copyright, and the information in it is confidential. Use of this = email or >>>>>>>> of any information in it other than by the addressee is unauthoris= ed and >>>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any at= tachments >>>>>>>> are virus-free, it is the recipient's sole responsibility to scan = all >>>>>>>> attachments for viruses. All calls and emails to and from this com= pany may >>>>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>>>> company's business. Any opinions expressed in this email (or in an= y >>>>>>>> attachments) are those of the author and do not necessarily repres= ent the >>>>>>>> opinions of Moneyhub Financial Technology Limited or of any other = group >>>>>>>> company. >>>>>>>> >>>>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>>>> Technology Limited which is authorised and regulated by the Financ= ial >>>>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entere= d on the >>>>>>>> Financial Services Register (FRN 809360) at >>>>>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>>>>> registered in England & Wales, company registration number 0690977= 2. >>>>>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterpr= ise, Regus >>>>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>>>> copyright, and the information in it is confidential. Use of this = email or >>>>>>>> of any information in it other than by the addressee is unauthoris= ed and >>>>>>>> unlawful. Whilst reasonable efforts are made to ensure that any at= tachments >>>>>>>> are virus-free, it is the recipient's sole responsibility to scan = all >>>>>>>> attachments for viruses. All calls and emails to and from this com= pany may >>>>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>>>> company's business. Any opinions expressed in this email (or in an= y >>>>>>>> attachments) are those of the author and do not necessarily repres= ent the >>>>>>>> opinions of Moneyhub Financial Technology Limited or of any other = group >>>>>>>> company. >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Dave Tonge >>>>>> CTO >>>>>> [image: Moneyhub Enterprise] >>>>>> >>>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>>> BS1 6FL >>>>>> >>>>>> t: +44 (0)117 280 5120 >>>>>> >>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at *https://register.fca.or= g.uk/ >>>>>> *. Moneyhub Financial Technology is >>>>>> registered in England & Wales, company registration number 06909772 >>>>>> . >>>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>>> Technology Limited which is authorised and regulated by the Financia= l >>>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered = on the >>>>>> Financial Services Register (FRN 809360) at >>>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>>> registered in England & Wales, company registration number 06909772. >>>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterpris= e, Regus >>>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>>> >>>>>> . >>>>>> >>>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>>> copyright, and the information in it is confidential. Use of this em= ail or >>>>>> of any information in it other than by the addressee is unauthorised= and >>>>>> unlawful. Whilst reasonable efforts are made to ensure that any atta= chments >>>>>> are virus-free, it is the recipient's sole responsibility to scan al= l >>>>>> attachments for viruses. All calls and emails to and from this compa= ny may >>>>>> be monitored and recorded for legitimate purposes relating to this >>>>>> company's business. Any opinions expressed in this email (or in any >>>>>> attachments) are those of the author and do not necessarily represen= t the >>>>>> opinions of Moneyhub Financial Technology Limited or of any other gr= oup >>>>>> company. >>>>>> >>>>>> >>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Tonge >>>>> CTO >>>>> [image: Moneyhub Enterprise] >>>>> >>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, >>>>> BS1 6FL >>>>> >>>>> t: +44 (0)117 280 5120 >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at *https://register.fca.org= .uk/ >>>>> *. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772 = . >>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at >>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772. >>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise= , Regus >>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>>> >>>>> . >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Dave Tonge >>>> CTO >>>> [image: Moneyhub Enterprise] >>>> >>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>>> 6FL >>>> >>>> t: +44 (0)117 280 5120 >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at *https://register.fca.org.= uk/ >>>> *. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772 . >>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA >>>> >>>> . >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6= FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000e6eecd05b6988b16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    This has been a great discussion, and we've opened thr= ee new issues to track things that came up in this thread that follow on fr= om the changes in the PR:

    * persistent grant identifier https://githu= b.com/ietf-wg-gnap/gnap-core-protocol/issues/146
    * rotation of toke= ns related to continuation request https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/147
    * special label for access token used for conti= nuation https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149
    The editors believe the specifics in this PR have rough consensus, so = we're going ahead with merging it.

    Aaron


    On Wed, Dec 16, 2020 at 3:37 AM Justin Richer <jricher@mit.edu> wrote:
    On Dec 16, 2020, at 5:15 AM, Warren Parad <wparad@rhosys.ch> wrote:

    #4 is a prer= eq for this discussion though. If the token is the identifier of the grant = then it must be in the url to avoid the problem of arbitrary url constructi= on. Of course the uri would be=C2=A0https://as/grants/{grantIden= tifier}. And this is actually independent of whether or not the tok= en gets rotated.

    That=E2=80=99s= not true: the identifier exposed to the client for some purpose like grant= extension doesn=E2=80=99t have to be the same identifier that the AS uses = for management. The latter is internal, and exposing internal state to the = protocol shouldn=E2=80=99t be a requirement to the pattern.=C2=A0

    =

    #3 The idea of a dynamic environment is important here, howev= er the argument doesn't justify having this being the same endpoint. No= thing stops us from having two endpoints, one that requests an access token= separate from the ones that manage the grant resource.

    Nobody said this has to be the same en= dpoint. In fact, this structure is being put in place to allow them to be s= eparate endpoints. My original design in XYZ used a single endpoint and exp= osed an internal identifier of the ongoing grant request to the client with= in the protocol (the transaction handle). Changing this to a properly abstr= acted and protected API pattern allows much greater flexibility. The AS now= has the choice of how it wants to manage its own dispatching, without the = client needing to be aware of any of it since the client always does the sa= me thing.

    =C2=A0=E2=80=94 Justin


    Warren Parad
    =
    Founder, CTO<= /div>
    Secure you= r user data and complete your authorization architecture. Implement=C2=A0Authress.


    On Wed, = Dec 16, 2020 at 10:09 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    >=C2=A0Dave: w= hich points changed your mind?

    1. T= he issue with re-using client authentication across endpoints in the OAuth = 2 world (token_endpoint_auth_methods_supported,=C2=A0revocation_endpoint_au= th_methods_supported,=C2=A0introspection_endpoint_auth_methods_supported...= )

    2. The clear a= rticulation of the 3 different functions of the AS (including the idea of a= self-hosted AS)

    3. The aim to support a more dynamic environment where client authent= ication only happens in the first interaction between the RC and the AS

    4. The agreement that there should be f= urther discussion on whether this access token should be rotated, and wheth= er it should be an identifier of the grant.


    On Wed, 16 Dec 2= 020 at 00:02, Dick Hardt <dick.hardt@gmail.com> wrote:
    Dave: which points chang= ed your mind?

    On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <dave.tonge@moneyhub.com<= /a>> wrote:
    <= div dir=3D"ltr">
    Thanks for the detailed response.

    I think you make the points well and I'm now = in favour of the PR.
    However I do think that to keep the c= onsistency that keeps being discussed, that the tokens shouldn't be rot= ated.=C2=A0

    I also think it would = be good to have a discussion about "grant management" and identif= iers for a grant.

    On Tue, 15 Dec 2020 at 17:30, Justin Richer <jricher@mit.edu> wrote:
    On Dec 15, 20= 20, at 10:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:

    >=C2=A0The access token pattern has a = lot of benefits, otherwise we wouldn=E2=80=99t have an entire OAuth ecosyst= em based on it

    But wha= t are the benefits=C2=A0in this particular use case?=C2=A0= The continuation API is not like any other API - it is integral to the AS. = There are quite a few extensions to OAuth that use client authentication ra= ther than access tokens.

    = Yes, and the propagation of that has lead to a mess in the OAuth world. You= =E2=80=99ve got re-definitions of client authentications at all different e= ndpoints, they=E2=80=99re technically allowed to vary between endpoints (th= ough I don=E2=80=99t know of it happening in practice, that feels like a do= wngrade attack waiting to happen to someone). Then there=E2=80=99s the fact= that all the newest security mechanisms we have =E2=80=94 PKCE, DPoP, and = MTLS =E2=80=94 don=E2=80=99t rely on client authentication at all to achiev= e security. All of these work without the client having credentials previou= sly known to the AS, and we already know that GNAP is going to need to live= in this more dynamic world. We need to think beyond what OAuth 2 has done = in the past, and especially from our perceptions and assumptions of the mod= els that drive OAuth 2=E2=80=99s decisions, lest we repeat its mistakes.=C2= =A0

    Also, I want to challenge this idea of =E2=80= =9Cintegral to the AS=E2=80=9D as a point. In OAuth 1, the API was =E2=80= =9Cintegral=E2=80=9D to the server side, but in OAuth 2 we split that into = the RS concept. Even though in practice, a lot of RS=E2=80=99s are still in= tegrated to the AS in some fashion because it=E2=80=99s a single service, O= Auth 2 is clear about what=E2=80=99s expected to be known by each component= . For the AS as currently defined in GNAP, I=E2=80=99m seeing three distinc= t functions. As per the Terminology discussion, we don=E2=80=99t have expli= cit names for these yet:

    =C2=A0- starting a reques= t; this is an endpoint to kick things off; it needs to be able to look up t= he rights asked for by the client (if it knows the client at all ahead of t= ime) and make initial decisions about needed interaction and follow up=C2=A0- continuing a request; this is an API that needs to know the contex= t of the request itself, including which key it=E2=80=99s bound to; this is= separate from any identity of the client and possibly the user, but an AS = implementation that has access to those elements can use them
    =C2= =A0- interacting with the user; this is front-facing and in OAuth today is = already deployed as a separate service in some places, we should embrace th= at at the very least (but doing so formally is a separate issue)
    =
    Why separate these in this way? There is immense power in ha= ving a single consistent way to start the process. The =E2=80=9Ccontinuatio= n API=E2=80=9D gives us an HTTP-defined mechanism for managing a request ov= er time, including the simple case of returning information from the front = channel, but people have already raised the question of non-HTTP and self-h= osted AS=E2=80=99s, which would probably want a different kind of continuat= ion API to communicate to the AS. The same thing with separating out the in= teraction: there are going to be a lot of different ways to handle interact= ion out there, and not all of them will be =E2=80=9Cintegral=E2=80=9D to th= e AS in the way that a simple implementation might do. We=E2=80=99re defini= ng a protocol based strongly on HTTP and JSON, but we should structure it i= n such a way that it can be extended and translated elsewhere in a clear wa= y.

    This all raises the question: if we can rely on a unique URL= for redirect-based interaction, why not here? The simple reason is that a = URL is the :only: mechanism we have in the front channel for passing inform= ation, and we need to warn implementors against including sensitive informa= tion in it, and we need to protect it with additional items. We have access= to more than just URLs when we=E2=80=99re dealing with the continuation AP= I, and we ought to make use of all of our tools in ways that are consistent= and make sense.

    From a previous email the advan= tages I see are:
    =C2=A0- more data can be= encoded in a token than in a uri (this seems more of an edge case)
    =C2=A0- it can be an identifier for the grant (I= don't agree with this)

    It allows the parts above to live separately, even if they don=E2=80=99t= HAVE to. And it simplifies what we=E2=80=99re asking the client to do by m= aking it consistent with other parts of the ecosystem. The AS offering an A= PI doesn=E2=80=99t :have: to be different, and OpenID Connect showed us, wi= th the UserInfo Endpoint, that that=E2=80=99s very much the case in practic= e.=C2=A0

    Having my client code do very similar thi= ngs in slightly different ways is not simpler.


    Another question I have:=C2=A0do we e= nvisage granting access tokens to the RC that will allow it to manage multi= ple grants?=C2=A0=C2=A0

    I don=E2=80=99t see that happening, personally, and it hasn=E2=80=99t be= en brought up as a use case to date.=C2=A0


    I also think there will be confusion with the signing be= ing used for different things. Maybe it just needs to be called out in the = spec that:

    Request 1: signature =3D client authentication
    Request 2+: signature =3D proof of possession for access= token


    That=E2=80=99s more or less the intent of what=E2=80= =99s in the specification right now, and why all the signature methods, whi= ch are used for both client auth and token possession, are all together in = section 8 and not separated by use. =C2=A0(With the caveat: it=E2=80=99s on= ly client authentication in the first request if the AS knows about the cli= ent instance ahead of time, which isn=E2=80=99t always going to be true.) T= hat all can likely be made clearer, as is always the case with spec text. B= ut you can use the signature methods with and without access tokens, and it= only gets used without in an initial call where you don=E2=80=99t :have: a= n access token to present.

    Separating the differen= t kinds of =E2=80=9Cclient authentication" out in OAuth is the source = of some real confusion. Like right now, what happens if you try to combine = a client assertion, signed request objects for PAR, and DPoP proofs, all in= a single request? All of these are optional and all of them =E2=80=9Cdo cl= ient authentication=E2=80=9D in some arguable fashion. I=E2=80=99ve worked = on several systems and implemented these things, and their interplay is rea= lly confusing to manage and can go sideways really fast. And that=E2=80=99s= just the work for a single endpoint, this gets repeated for introspection,= revocation, CIBA, device, and on.

    At the end of t= he day I=E2=80=99m in favor of giving the client developers a very clear se= t of directions on what they need to do and how they need to access things,= and treating the continuation as a token-bound API is, to me, the clearest= pattern we can offer for this piece.

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





    <= div class=3D"gmail_default">



    On Tue, 15 Dec 2020 at 15:33, Justin Richer <jricher@mit.edu> wrote:
    I agree with Fabie= n that the persistent identifier is a separate issue. The current spec re-u= ses the access token for this artifact, but that=E2=80=99s potentially brit= tle and could be changed out for something else. There=E2=80=99s an issue a= sking for expanding on the use cases for this functionality (which hasn=E2= =80=99t been addressed by this PR):


    =
    A potentially-rotating URI would be just as brittle, and so having a s= ingle codified identifier for this artifact would be useful, but it does as= sume some things about the nature of the AS. Every other use the client has= to manage the ongoing request over time doesn=E2=80=99t need an explicit i= dentifier. Just like with OAuth-protected APIs, the server can determine th= e context not just from the URI but from the rest of the request, including= the access token itself. This is both more common and more powerful than a= strict reading of REST designs. It also follows the HATEOS principles as t= he entire HTTP request is taken into account, including the access token an= d signature portions.=C2=A0

    I=E2=80=99ll also poin= t out that the rotation of these credentials is also filed as a separate is= sue that=E2=80=99s not being addressed right now, so we can revisit that di= scussion separately:


    As f= or the name, we could give it a different label. We have this same pattern = of issuing a resource-specific access token alongside a URL in the Dynamic = Registration specification, both in OAuth (https://tools.ietf.org/html/rfc= 7592#section-3) and OpenID Connect (https://openid.net/specs/openid-connect-registration-1_0.html#Registrati= onResponse). Here it=E2=80=99s called the =E2=80=9Cregistration access = token=E2=80=9D =E2=80=94 but what=E2=80=99s important there, as it is here,= is that it=E2=80=99s not a different kind of artifact that the client now = has to figure out how to use, it=E2=80=99s an access token plain and simple= . In the OAuth world this is a bearer token, since that=E2=80=99s what OAut= h 2 uses. In the GNAP world it=E2=80=99ll be a bound token, as that=E2=80= =99s what we=E2=80=99re looking to build on. This is also related to anothe= r future discussion about responses tying an access token to a specific API= that=E2=80=99s told to the client, as we could potentially re-use those co= mponents and concepts here as well:


    And finally, no speculation on the complexity is needed: I= implemented this pattern several months ago during the design team discuss= ions when we were considering this pattern, and the code is all online for = people to see.=C2=A0


    On the AS side, the most interesting cod= e to this discussion is in the TransactionEndpoint class:




    The heavy lift is doing the a= ctual signing, and you need that in order to start the process anyway. Mana= ging the access token as an artifact to use at the API is completely trivia= l since the client already needs to manage its own state internally to do a= ny of this. And note that all of this is changed from how it was before: Pr= eviously, the XYZ Protocol had used a =E2=80=9Ctransaction handle=E2=80=9D = returned by the AS that the client would use to continue the request. Howev= er, this simple model was limiting, and the design team adopted XAuth=E2=80= =99s model of continuation being an API. In doing so, we made it like all o= f the other APIs the client is going to call: in the initial state, it does= n=E2=80=99t have any kind of access rights, it=E2=80=99s just calling. From= that initial call forward, the AS just needs to know that the token and ke= y match what it expects.=C2=A0

    In summary, my view= s are:
    =C2=A0- The access token pattern has a lot of benefits, ot= herwise we wouldn=E2=80=99t have an entire OAuth ecosystem based on it
    =C2=A0- Magic URIs have a lot of drawbacks which are well understood;= while they can be mitigated, they can also be avoided
    =C2=A0- Co= ntinuation is an API, and treating it like the other kinds of API the clien= t would call makes sense
    =C2=A0- Calling this by a special name, = like =E2=80=9Cgrant access token=E2=80=9D or =E2=80=9Ccontinuation access t= oken=E2=80=9D is fine, but it should function like any other access token
    =C2=A0- The heavy lift for clients is on protecting the message cr= yptographically, which they need to do anyway

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


    O= n Dec 15, 2020, at 7:50 AM, Dave Tonge <dave.tonge@moneyhub.com> wrote:
    The persistent identifier=C2=A0is not a= different issue, the current access token is used to=C2=A0reference an existing grant=C2=A0

    <= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif">It may not be more difficult for a client to=C2=A0<= b style=3D"font-family:"trebuchet ms",sans-serif">use= =C2=A0an access token at the AS / RS. But there=C2=A0is definitely a= n overhead on the client to=C2=A0manage=C2=A0this separate access token.= =C2=A0



    On Tue, 15 Dec 2020= at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I think we always= said the access token was different, and handled as a bound token.
    But it doesn't mean it's more difficult for the client = that already needs to be able to handle tokens anyway (bearer or not, both = cases could occur). It's mostly consolidating the logic.

    You're anticipating a lot of issues which have no speci= fic reason to occur, such as "can't be used with the token management APIs?&q= uot;. The management API is part of the same general flow.
    Anticipati= ng issues with rotation is useful, but there are also many ways it can be h= ard to manage through a stateful approach too. And fundamentally, having ev= erything in a common model (both for the internals of the AS and for the AP= I calls) will help improve by a large margin what is probably the weakest p= oint in today's infrastructure. But it's early to be definitive as = to the downstream impact either way.=C2=A0 =C2=A0

    As f= or a persistent identifier instead of a continuation API, and generally the= end of your message, it's a totally unrelated issue to this PR, so I s= uggest we don't discuss that here, but in a separate issue if needed.

    Fabien

    On Tue, Dec 15, 2020 at 11= :08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've = established that this is a different access token, that requires different = handling at the client. So keeping it could cause more confusion?

    As an RC, I will have to store the continue `= uri` as although it could be static it could also be dynamic. Why do I need= to store an access token as well.=C2=A0It brings me no benefit as an RC, i= n fact it brings more complexity. As I will now need to manage multiple typ= es of tokens with different lifecycles:

    Continuati= on token=C2=A0
    =C2=A0 - can only be used at the contin= ue endpoint (the name of which is confusing as I can use this endpoint to r= evoke a grant or get metadata on the grant).
    =C2=A0- may b= e rotated each time it is used, or may not be
    =C2=A0- prov= ided in the `continue` section of the response
    =C2=A0- mus= t be sender-constrained
    =C2=A0- can't be used with the= token management APIs?
    =C2=A0- can be used to identify th= e grant when making subsequent grants

    Access token= (s) to use at RS
    =C2=A0=C2=A0- can only be used at the specified= RS
    =C2=A0 - may be sender constrained
    = =C2=A0 - when used at the RS, will not result in rotation
    From my perspective, most use-cases will require th= e RC to have a persistent identifier for the grant. Why not bring this into= the protocol and let the AS provide this persistent identifier (through th= e form of the continue uri). Using a rotating access token as a persistent = identifier doesn't seem like the right choice.=C2=A0
    <= br>
    I see no security benefit to having the continuation a= ccess token. It doesn't matter if the continue uri leaks as it is usele= ss without an accompanying signature, i.e. any security benefit of having a= n access token is already provided by having a signature.
    The only benefits that I can see are:
    =C2=A0- If the AS wants to be fully stateless, then you can encode more= data in a token than in a uri
    =C2=A0- If the AS wants to = have a static endpoint for CRUD operations on the grant
    = =C2=A0- To allow the AS to identity a previous grant

    <= /div>
    If we dropped the access token for the continue endpoint a= nd rather mandated a dynamic uri this would make things conceptually easier= to understand, easier for the RC to implement, easier to debug and less ch= ance of errors when rotating tokens (i.e. race conditions could be quite li= kely if the AS always rotates the token)

    One-off g= rant with no continuation or ongoing management:
    RC se= nds signature and metadata, no `continue` response provided, therefore no g= rant management possible

    Grant with ongoing manage= ment
    RC sends signature and metadata, AS responds with= a continue uri that has these purposes:
    =C2=A0- can be us= ed by the RC to continue/update, read or revoke the grant

    As an RC the only perm= anent items I need to store are:
    =C2=A0- the continue uri = associated with the grant
    =C2=A0- any access tokens I rece= ive for the grant

    Dave
    On Tue, = 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Tor= sten,=C2=A0

    You're right on both accounts.=C2=A0
    - for the first remark, it fits quite nicely the init request=C2=A0 = / continuation pattern=C2=A0
    - for the second remark, it is a sor= t of handle for the continuation=C2=A0request, which will eventually lead t= o the issuance or refresh of standard access tokens=C2=A0

    Having a specific=C2=A0name is a possibility, I actually suggested = that too at some point.=C2=A0

    Fabien
    On Tue, = Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,= =C2=A0

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <= ;fabien.imbau= lt@gmail.com>:
    >=C2=A0
    > Hi,
    >= =C2=A0
    > On the contrary your feedback is most welcome.= =C2=A0
    >=C2=A0
    > It doesn't accept any = token, it needs the particular token as described in 3.1 and which is not a= bearer token (that's what the "key" : true parameter is supp= osed to convey).=C2=A0
    >=C2=A0
    > Let = us know if you need more clarifications.=C2=A0

    Thanks f= or the clarification. I think only accepting this kind of token at the cont= inuation is a good idea otherwise the AS would need to be able to parse and= understand all sorts of access tokens.

    Conceptually, I like the ide= a to treat the continuation as another kind of resource. However, here are = some observations I want to share with you:=C2=A0
    - This re= source is different as it will issue other access tokens (of this kind) to = be used in subsequent continuation requests. This requires different handin= g on the client side.
    - This access token (if I understand correctly) is= (or at least feels like) a handle for the underlying grant. So it is kind = of the super access token to obtain other access tokens.=C2=A0=

    I would consider using a different term to refer to this special ac= cess token, grant token or grant handle for example, in order to prevent co= nfusion.=C2=A0

    best regards,
    Torsten.=C2=A0


    >=C2=A0
    > Best
    > Fabien= =C2=A0
    >=C2=A0
    > Le sam. 12 d=C3=A9c. 2020 = =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.net> a =C3=A9crit :
    &= gt; Hi all,
    >=C2=A0
    > I didn=E2=80=99t follow GNAP= closely so bear with me if me question seems naive.
    >=C2=A0
    > After having skimmed through the current draft and the PR, I= =E2=80=98m not sure whether the continuation requests accepts any access to= ken issued to the RC or the particular access token returned in the =E2=80= =9Econtinue=E2=80=9C element in section 3.1..
    >=C2=A0> Can you please shed some light on this?
    >=C2=A0> kind regards,
    > Torsten.
    >=C2=A0
    >>= Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com>:
    = >>=C2=A0
    >> =EF=BB=BF
    >> You're co= mpletely right. Allowing the dev to be lazy is a very good thing in general= , because it's what we know will work :-)=C2=A0
    >>= ;=C2=A0
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, St= ephen Moore <srmo= ore@gmail.com> a =C3=A9crit :
    >> Hi Fabien,
    >>=C2=A0
    >> For #3) Even after I typed out the hypothetical= attack, that was sort of in the back of my mind, it isn't a huge risk = there. So I actually agree with Dick there. Something doesn't sit right= with me for the unique URL solution, so I don't like it and came up wi= th a hypothetical that seems like it could be a down side.
    >>=C2=A0
    >> I still think the access token model with the si= gned request is the way I'd like to go, because again, it's a mecha= nism I'd be implementing anyway to talk to any 'normal' resourc= e. The fact is there is _something_ representing context that has to pass b= ack and forth here, whether that is an access token (which I feel like is m= ore flexible for extensions etc), a unique url, or even a cookie sent in th= e cookie header. So just to re-iterate, I'm a +1 on this pull request, = speaking as a lazy developer ;)
    >> -steve
    >>=C2=A0<= /span>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gma= il.com> wrote:
    >> Again speaking in my own name here.= =C2=A0
    >>=C2=A0
    >> Dick, we know you&= #39;d prefer to have a different design, but this PR shouldn't be about= that.=C2=A0
    >>=C2=A0
    >> Back o= n your 3 items :
    >>=C2=A0
    >> 1) yes we could= make pre-register mandatory, but we already decided that wouldn't be h= ow that would work. We have a client instance that allows a more generic an= d flexible pattern (which BTW also allows what you want)=C2=A0=
    >>=C2=A0
    >> 2) instead of blame arguments o= f who's less restful/HATEOAS/whatever that have the tenancy to flame co= nversations, I suggest we speak in less abstract terms and ask ourselves wh= at that means in practice for devs. Stephen and several others (myself incl= uded) have expressed that it wouldn't be harder to implement, it would = even simplify things quite a lot. If you disagree please send us a code sam= ple to really show that point by example, because that's really not obv= ious.=C2=A0
    >>=C2=A0
    >> 3) &quo= t;If someone has the client credentials, they can impersonate the client, a= nd all bets are off." Are you seriously making this argument? Because = if you have a better proposal than using cryptographic keys, I'm all he= ars. You make it look like there's a problem, while in reality we'r= e only relying on the basic assumption of all modern digital communications= .=C2=A0
    >>=C2=A0=C2=A0
    >> And m= ore importantly you never responded to the issues of how to avoid the secur= ity pitfalls of what you proposed.=C2=A0
    >>=C2= =A0
    >> Fabien=C2=A0
    >>=C2=A0
    >>=C2=A0
    >> Le sam. 12 d=C3=A9c. 2020 = =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit :
    >>= =C2=A0
    >>=C2=A0
    >> On Fri, Dec 11, 20= 20 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:=
    >> "
    >> When sending a non-continuation request to = the AS, the RC MUST identify itself by including the client field of the re= quest...
    >> ...
    >> key (object / string) : The public key= of the RC to be used in this request as described in {{request-key}}. This= field is REQUIRED.=C2=A0
    >> ...
    >> ">> So on the initial request, the key will be there.=C2=A0
    >>=C2=A0
    >> The client field can be an = object or a string. If the client is pre-registered, then a string could be= provided instead of an object.
    >>=C2=A0=C2=A0
    >= ;>=C2=A0
    >> If you don't have the access token= , then how do you differentiate between two requests from the same web appl= ication by two different users? Is the web application supposed to have dif= ferent credentials for every request?
    >>=C2=A0
    >= ;> The AS returns a URI for manipulating the request. I would change the= spec so that each request would have a unique URI. This is the usually RES= Tful pattern that the resource (the grant request) has an URI.
    >><= span>=C2=A0
    >>=C2=A0=C2=A0
    >> So in t= his case, the easy way out is to pass the access token to the client, who t= hen, as i stated before, treats the continue request as a RS call (albeit a= specialized version of the RS where the RS is the AS) OR to use the unique= URL,=C2=A0
    >> but that seems open to a brute force a= ttack by a malicious RC. (What would be the point of that attack, I don'= ;t know, I guess if someone had the client credentials but not any subjects= /resources they could try to intercept the grant via continue... I just don= 't feel right locking things down to unique URLs that way.)
    >>= =C2=A0
    >> If someone has the client credentials, they= can impersonate the client, and all bets are off.
    >>=C2=A0<= /span>
    >> LOTS of RS servers return a resource specific URL -- my = proposal is no different.
    >>=C2=A0
    >>= =C2=A0
    >>=C2=A0=C2=A0
    >> -steve
    &g= t;>=C2=A0
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick = Hardt <dick.ha= rdt@gmail.com> wrote:
    >> Hi Stephen
    >>=C2=A0=
    >> The client is signing the first request. The key *might= * be in the body. The client is signing all the subsequent requests as well= . The "access token" is not needed by the client to prove it is a= uthorized as the client is proving it is the same client again.
    >>= =C2=A0
    >> In other words, I don't see the need fo= r an access token, so it does not need to be put in a URL or an auth header= .
    >>=C2=A0
    >> If a developer really, really = wants to hand context back to the client for subsequent calls, they can put= it in the URL or some other method. Putting it in the HTTP Authorization h= eader is confusing because it is NOT an access token -- it is the context o= f the request.
    >>=C2=A0
    >> =E1=90=A7
    >= >=C2=A0
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen= Moore <srmoore@g= mail.com> wrote:
    >> Even though I've only been lightly = following things, I feel the need to voice my preference as a developer sin= ce I will probably someday have to either write a RC or RS...=C2=A0
    >>=C2=A0
    >> The way I see it is the RC= makes the initial request to the AS as part of this request, it provides i= t's key in the body... (So no use of the Authorization header)
    >&= gt; At this point that request, represented by the continue URL + "Acc= ess Token", from my lazy developer standpoint, is a Resource Endpoint = and Access Token, and the AS is acting as a specialized RS in this case.>> So my client posts to whatever URL with the 'access token'= ; in the authorization header, just like acting on any other resource I hav= e a token for. YES, I get a new token value to use every call, and there is= a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client.
    >> Personally I like that, because if I have an access_tok= en, I already think "Put it in the auth header."=C2=A0
    >>=C2=A0
    >> So my vote would be +1 for th= e pull request at this time.
    >> -steve
    >>=C2=A0
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> = wrote:
    >> inline ...=C2=A0
    >>=C2=A0
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote= :
    >> Others had already responded to this previous thread, but I w= anted to add a couple points to clarify some things.
    >>=C2= =A0
    >>> 3) What the client has to do with the "acce= ss token" is not the same as access tokens for an RS. The client gets = a new "access token" for each grant request, and for each API cal= l to the AS, and the client learns it can not make any more API calls for t= hat specific request when it does not get an "access token" back.= This is a completely different design pattern than calling an RS API with = an access token, and is a new design pattern for calling APIs. This adds co= mplexity to the client that it would not normally have, and I don't thi= nk GNAP is the right place to start a new design pattern.
    >>>=C2=A0
    >>=C2=A0
    >> I=E2=80=99m no= t sure what you mean by these being different =E2=80=94 the whole point of = the design is that the client would be doing the same thing with the access= token at the AS that it does with the RS by re-using the access token stru= cture. Can you please describe what the differences are, apart from the rot= ation? Presentation of the token and signing of the message are identical.<= br>>>=C2=A0
    >> The client is getting the "= access token" from its API. It is not using an "access_token"= ; in other API calls to the AS.
    >>=C2=A0=C2=A0
    >= ;>=C2=A0
    >> Rotation of the access token and artif= acts for ongoing continuation responses is a separate issue to be discussed= :=C2=A0https://github.com/i= etf-wg-gnap/gnap-core-protocol/issues/87
    >>=C2=A0=
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right = place to have new designs =E2=80=94 not that this is one.
    >>= =C2=A0
    >> You are proposing a new way for an API to provide= context for subsequent API calls. Looks out of scope to me.
    >>=C2= =A0=C2=A0
    >>=C2=A0
    >>> 4) Cl= ients that only want claims from the AS and no access tokens will be requir= ed to support an API calling mechanism they would not have to support other= wise.=C2=A0
    >>=C2=A0
    >> Correct= , but the delta between the calls a client would make with and without an a= ccess token is vanishingly small. The client has to sign the initial reques= t in some fashion, and it will sign the continuation request in the same ex= act fashion, but now include an access token in that request.=C2=A0
    >>=C2=A0
    >> Per my other point, there = is no value to me in my implementations of passing context back and forth b= etween the client and AS -- so it is extra work providing no value.
    >= >=C2=A0
    >> Also, any client authentication mechani= sm that wants to use the HTTP Authentication header is precluded from using= it.
    >>=C2=A0
    >>=C2=A0=C2=A0>>=C2=A0
    >> Clients making a request to an AS = and not getting an access token is a new design pattern. I think it has val= ue and should be included, but OAuth today shows us the immense value of ge= tting access tokens for calling APIs, and so we shouldn=E2=80=99t optimize = away from that pattern.
    >>=C2=A0
    >>>=C2=A0
    >>> 5) If the AS does not provide an "acces= s token", there is no mechanism for a client to delete the request, as= the client is not allowed to make a call without an "access token&quo= t;.
    >>=C2=A0
    >> More properly, if the AS doe= s not provide a =E2=80=9Ccontinue=E2=80=9D field then the client can=E2=80= =99t delete the request =E2=80=94 and yes, that=E2=80=99s intentional. The = AS is telling this client instance that it can=E2=80=99t do anything else w= ith this ongoing request. If the AS wants to allow the client to manage it,= it will include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D = field.
    >>=C2=A0
    >> There is nuance in that i= ntention. A related concern is that deleting a request does not seem like i= t is a "continue" operation.
    >>=C2=A0=C2=A0=
    >>=C2=A0
    >>>=C2=A0
    >&= gt;> 6) There is no standard identifier for the request. Debugging and a= uditing are hampered by the client and AS having no standard way to identif= ying a request. While one AS may provide a unique URL for each grant reques= t, another AS may use a persistent "access token" to identify the= grant request, and other ASs may issue a new "access token" on e= ach API call, providing no persistent identifier for the request.
    >&g= t;=C2=A0
    >> Debugging and auditing this kind of thing= are functions of the AS. How is interoperability harmed by different ASs h= aving different methods to identify their internal data elements? The clien= t doesn=E2=80=99t need any knowledge of the AS=E2=80=99s identifiers, it ju= st needs to know the next steps for continuing the negotiation.
    >>= =C2=A0
    >> Debugging between the client and the AS was= what I was referring to. How does a client developer identify the request = when communicating to the AS developer. Seems complicated.
    >>=C2= =A0=C2=A0
    >> =E1=90=A7
    >> --=C2=A0
    >> TXAuth mailing list
    >>=C2=A0TXAuth@ietf.org
    >&g= t;=C2=A0https://www.ietf.org/mailman/listin= fo/txauth
    >> =E1=90=A7
    >> --=C2=A0
    &g= t;> TXAuth mailing list
    >>=C2=A0TXAuth@ietf.org
    >>=C2= =A0https://www.ietf.org/mailman/listinfo/txauth
    >> --=C2=A0
    >> TXAuth mailing list
    >= ;>=C2=A0    TXAuth@ietf.org
    >>=C2=A0https://www.google.com/url?q=3Dh= ttps://www.ietf.org/mailman/listinfo/txauth&source=3Dgmail-imap&ust= =3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJYtSpI

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


    --=C2=A0
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technol= ogy, 5th Floor,=C2=A010 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is a trading sty= le of Moneyhub Financial Technology Limited which is authorised and regulat= ed by the Financial Conduct Authority ("FCA").=C2=A0Moneyhub Fina= ncial Technology is entered on the Financial Services Register=C2=A0= (FRN=C2=A0809360) at=C2=A0https://register.fca.org.uk/. M= oneyhub=C2=A0Financial Technology = is registered in England & Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019= =C2=A0=C2=A9

    DISCLAIMER: This email (including any att= achments) is subject to copyright, and the information in it is confidentia= l. Use of this email or of any information in it other than by the addresse= e is unauthorised and unlawful. Whilst reasonable efforts are made to ensur= e that any attachments are virus-free, it is the recipient's sole respo= nsibility to scan all attachments for viruses. All calls and emails to and = from this company may be monitored and recorded for legitimate purposes rel= ating to this company's business. Any opinions expressed in this email = (or in any attachments) are those of the author and do not necessarily repr= esent the opinions of Moneyhub Financial Technology Limited or of any other= group company.

    Moneyhub Enterprise is a trading style of Moneyhub Financial Technology= Limited which is authorised and regulated by the Financial Conduct Authori= ty ("FCA"). Moneyhub Financial Technology is entered on the Finan= cial Services Register (FRN 809360) at=C2=A0https://register.fca.org.uk/. Moneyh= ub Financial Technology is registered in England & Wales, company regis= tration number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 = Moneyhub Enterprise, Regus Building, Temple Quay,=C2=A01 Friary= , Bristol, BS1 6EA.=C2=A0

    DI= SCLAIMER: This email (including any attachments) is subject to copyright, a= nd the information in it is confidential. Use of this email or of any infor= mation in it other than by the addressee is unauthorised and unlawful. Whil= st reasonable efforts are made to ensure that any attachments are virus-fre= e, it is the recipient's sole responsibility to scan all attachments fo= r viruses. All calls and emails to and from this company may be monitored a= nd recorded for legitimate purposes relating to this company's business= . Any opinions expressed in this email (or in any attachments) are those of= the author and do not necessarily represent the opinions of Moneyhub Finan= cial Technology Limited or of any other group company.



    --<= span>=C2=A0
    Dave Tonge
    C= TO
    3D"Moneyhub
    Moneyhub Financial Technology, 5th Floor,=C2=A010 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120<= /span>

    Mon= eyhub Enterprise is a trading style of Moneyhub Financial Technology Limite= d which is authorised and regulated by the Financial Conduct Authority (&qu= ot;FCA").=C2=A0Moneyhub Financial Technology is entered on the Financi= al Services Register=C2=A0(FRN=C2=A0809360) at=C2=A0https://register.fca.org.uk/= . Moneyhub=C2=A0Financial Technology is registered in England & Wales, compa= ny registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Fin= ancial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in = it other than by the addressee is unauthorised and unlawful. Whilst reasona= ble efforts are made to ensure that any attachments are virus-free, it is t= he recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorde= d for legitimate purposes relating to this company's business. Any opin= ions expressed in this email (or in any attachments) are those of the autho= r and do not necessarily represent the opinions of Moneyhub Financial Techn= ology Limited or of any other group company.
    =

    Moneyhub Enterprise is a trading style of = Moneyhub Financial Technology Limited which is authorised and regulated by = the Financial Conduct Authority ("FCA"). Moneyhub Financial Techn= ology is entered on the Financial Services Register (FRN 809360) at= =C2=A0https://register= .fca.org.uk/. Moneyhub Financial Technology is registered in Eng= land & Wales, company registration number 06909772. Moneyhub Financial = Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple = Quay,=C2=A01 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachme= nts) is subject to copyright, and the information in it is confidential. Us= e of this email or of any information in it other than by the addressee is = unauthorised and unlawful. Whilst reasonable efforts are made to ensure tha= t any attachments are virus-free, it is the recipient's sole responsibi= lity to scan all attachments for viruses. All calls and emails to and from = this company may be monitored and recorded for legitimate purposes relating= to this company's business. Any opinions expressed in this email (or i= n any attachments) are those of the author and do not necessarily represent= the opinions of Moneyhub Financial Technology Limited or of any other grou= p company.



    --=C2=A0
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth
    <= br clear=3D"all">

    --=C2=A0
    <= div dir=3D"ltr">
    Dave Tonge
    CTO
    3D"Moneyhub
    <= div style=3D"padding:8px 0px;font-family:lato,"open sans",arial,s= ans-serif">Moneyhub Financial Technology, = 5th Floor,=C2=A010 = Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120
    Moneyhub Enterprise is a trading style of M= oneyhub Financial Technology Limited which is authorised and regulated by t= he Financial Conduct Authority ("FCA").=C2=A0Moneyhub Financial T= echnology is entered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at=C2=A0https://register.fca.org.uk/. M= oneyhub=C2=A0Financial Technology is regi= stered in England & Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0<= /span>=C2=A9

    DISCLAIMER: This email (including any attachments= ) is subject to copyright, and the information in it is confidential. Use o= f this email or of any information in it other than by the addressee is una= uthorised and unlawful. Whilst reasonable efforts are made to ensure that a= ny attachments are virus-free, it is the recipient's sole responsibilit= y to scan all attachments for viruses. All calls and emails to and from thi= s company may be monitored and recorded for legitimate purposes relating to= this company's business. Any opinions expressed in this email (or in a= ny attachments) are those of the author and do not necessarily represent th= e opinions of Moneyhub Financial Technology Limited or of any other group c= ompany.
    <= /div>

    Mo= neyhub Enterprise is a trading style of Moneyhub Financial Technology Limit= ed which is authorised and regulated by the Financial Conduct Authority (&q= uot;FCA"). Moneyhub Financial Technology is entered on the Financial S= ervices Register (FRN 809360) at=C2=A0https://register.fca.org.uk/. Moneyhub Fi= nancial Technology is registered in England & Wales, company registrati= on number 06909772. Moneyhub Financial Technology Limited 2020 =C2=A9 Money= hub Enterprise, Regus Building, Temple Quay,=C2=A01 Friary, Bri= stol, BS1 6EA.=C2=A0

    = DISCLAI= MER: This email (including any attachments) is subject to copyright, and th= e information in it is confidential. Use of this email or of any informatio= n in it other than by the addressee is unauthorised and unlawful. Whilst re= asonable efforts are made to ensure that any attachments are virus-free, it= is the recipient's sole responsibility to scan all attachments for vir= uses. All calls and emails to and from this company may be monitored and re= corded for legitimate purposes relating to this company's business. Any= opinions expressed in this email (or in any attachments) are those of the = author and do not necessarily represent the opinions of Moneyhub Financial = Technology Limited or of any other group company.




    --=C2=A0
    Dave Tonge
    CTO
    3D"Money=
    Moneyhub Financial Technology, 5th Floor,=C2=A0= 10 Temple Back, Bristol, = BS1 6FL
    t:=C2=A0+44 (0)= 117 280 5120

    Moneyhub Enterprise is a trading style of Moneyhub Financial Tech= nology Limited which is authorised and regulated by the Financial Conduct A= uthority ("FCA").=C2=A0Moneyhub Financial Technology is entered o= n the Financial Services Register=C2=A0(FRN=C2=A08093= 60) at=C2=A0https://register= .fca.org.uk/. Moneyhub= =C2=A0Financial Technology is registered in England & = Wales, company registration number=C2=A0=C2=A006909772=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9
    = DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments = for viruses. All calls and emails to and from this company may be monitored= and recorded for legitimate purposes relating to this company's busine= ss. Any opinions expressed in this email (or in any attachments) are those = of the author and do not necessarily represent the opinions of Moneyhub Fin= ancial Technology Limited or of any other group company.
    =

    Moneyhub Enterprise is a trad= ing style of Moneyhub Financial Technology Limited which is authorised and = regulated by the Financial Conduct Authority ("FCA"). Moneyhub Fi= nancial Technology is entered on the Financial Services Register (FRN 80936= 0) at=C2=A0https= ://register.fca.org.uk/. Moneyhub Financial Technology is regist= ered in England & Wales, company registration number 06909772. Moneyhub= Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildi= ng, Temple Quay,=C2=A01 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including a= ny attachments) is subject to copyright, and the information in it is confi= dential. Use of this email or of any information in it other than by the ad= dressee is unauthorised and unlawful. Whilst reasonable efforts are made to= ensure that any attachments are virus-free, it is the recipient's sole= responsibility to scan all attachments for viruses. All calls and emails t= o and from this company may be monitored and recorded for legitimate purpos= es relating to this company's business. Any opinions expressed in this = email (or in any attachments) are those of the author and do not necessaril= y represent the opinions of Moneyhub Financial Technology Limited or of any= other group company.




    --=C2=A0
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Tec= hnology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44= (0)117 280 5120
    <= br>
    Moneyhub Enterprise is a trading style of = Moneyhub Financial Technology Limited which is authorised and regulated by = the Financial Conduct Authority ("FCA").=C2=A0Moneyhub Financial = Technology is entered on the Financial Services Register=C2=A0(FRN=C2=A0809360) at=C2=A0https://register.fca.org.uk/. Moneyhub=C2=A0Financi= al Technology is registered in England & Wales, company registration nu= mber=C2=A0=C2=A00690977= 2=C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2= 019=C2=A0=C2=A9

    D= ISCLAIMER: This email (including any attachments) is subject to copyright, = and the information in it is confidential. Use of this email or of any info= rmation in it other than by the addressee is unauthorised and unlawful. Whi= lst reasonable efforts are made to ensure that any attachments are virus-fr= ee, it is the recipient's sole responsibility to scan all attachments f= or viruses. All calls and emails to and from this company may be monitored = and recorded for legitimate purposes relating to this company's busines= s. Any opinions expressed in this email (or in any attachments) are those o= f the author and do not necessarily represent the opinions of Moneyhub Fina= ncial Technology Limited or of any other group company.
    <= /div>

    Moneyhub Enterprise is a trading style of Moneyhub Financial Tec= hnology Limited which is authorised and regulated by the Financial Conduct = Authority ("FCA"). Moneyhub Financial Technology is entered on th= e Financial Services Register (FRN 809360) at=C2=A0https://register.fca.= org.uk/. Moneyhub Financial Technology is registered in England = & Wales, company registration number 06909772. Moneyhub Financial Techn= ology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay,= 1 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any attachment= s) is subject to copyright, and the information in it is confidential. Use = of this email or of any information in it other than by the addressee is un= authorised and unlawful. Whilst reasonable efforts are made to ensure that = any attachments are virus-free, it is the recipient's sole responsibili= ty to scan all attachments for viruses. All calls and emails to and from th= is company may be monitored and recorded for legitimate purposes relating t= o this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily represent t= he opinions of Moneyhub Financial Technology Limited or of any other group = company.


    --=C2=A0
    TXAuth mailing list<= br>TXAuth@ietf.org=
    https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000e6eecd05b6988b16-- From nobody Wed Dec 16 11:46:52 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F26F3A0E9F for ; Wed, 16 Dec 2020 11:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 CZ1D41G6UWua for ; Wed, 16 Dec 2020 11:46:44 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFA93A0E9E for ; Wed, 16 Dec 2020 11:46:44 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id i18so25140351ioa.1 for ; Wed, 16 Dec 2020 11:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=x0iHMigRqldPDNgmz+CipDhzHt62Ajew2n3Y1gdU05w=; b=akGZTl1bWlbIiR6OkkpaGTcI5QTqmL8ZyWEg3Whb0qxTlmrwsCdOjizMi9CAQsiF4z VhEepdzS/zlol9Dbhr4djfb4rNKz4apn+EJo9zpdmPI9S1rKZPphHzkbIhnxSzqMGhbY 7v6K9F+MhmzPqKWU/pIvbU7zXCNpKZsA2d8wjS4MzpC9Iq/ChDkNkBT3L3Y9ZQp5Z8la Ix/Mrln9kiV/h0uqOvv22PoFVKlpw3hRRdxUyVfii+6UpdQz+z5Lrhox3fFd5xLiq841 WGUPmf0Ur2Oj8LCjVhAP5T0DMJXajCBTDziA4jFnsAOd/iqN7kmjpk0BlXnjYFYQZve+ iF5A== 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=x0iHMigRqldPDNgmz+CipDhzHt62Ajew2n3Y1gdU05w=; b=Ge2WkPVzYP8IIrkx3pBCxEkjIB8pYA9kip6WRUW7DhRBaMTkFcaZsJy2rFDJ1D7VTV kRLPZ6axo+5C/uCc2D7yWbq5wOQHhT8MwC3YET+UbrR2KqYnUO4rLqGP/DkKk+gAy9UJ jCClkA7KU3N8weEwLHnkhBrOCQVrS4ICJRKqEaCehjM+qsghtTNV6zr+A5jYy23iplzH cqqf6dzRAwaKv2CvRvne8aMpoeLRSrWRUEQgwOwQ4ruBDzoyHJBwQiw+qnbxk7kIeRx4 B+MQRz0cQAWth4qGqjSL7BLlYjAhmuYJ4ZImMXMvH4M2wioZxHY9Vt0Lsr/NvYSAuzpp HTsA== X-Gm-Message-State: AOAM5329nfpO84mddgjGdXvFNz1H2KU+QRpaR9Ol4qUU3kfkwz1TX0EN udlkcu5uR1gHshj6anUAUSAiWyQ2gyRxiw== X-Google-Smtp-Source: ABdhPJxnt6VKtOSE32bsUc3QgeNdoiVKXHYEGtd4DqqjjtqGsheso66AiDfVdP3Ls8dRYQ+8cpPmOw== X-Received: by 2002:a6b:8f94:: with SMTP id r142mr28865408iod.115.1608148003266; Wed, 16 Dec 2020 11:46:43 -0800 (PST) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id z13sm13121543iof.19.2020.12.16.11.46.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Dec 2020 11:46:42 -0800 (PST) Received: by mail-il1-f171.google.com with SMTP id 75so11644316ilv.13 for ; Wed, 16 Dec 2020 11:46:42 -0800 (PST) X-Received: by 2002:a05:6e02:13e2:: with SMTP id w2mr1908254ilj.255.1608148001955; Wed, 16 Dec 2020 11:46:41 -0800 (PST) MIME-Version: 1.0 From: Aaron Parecki Date: Wed, 16 Dec 2020 11:46:31 -0800 X-Gmail-Original-Message-ID: Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000006723f705b69a2246" Archived-At: Subject: [GNAP] PRs pending merge X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 19:46:52 -0000 --0000000000006723f705b69a2246 Content-Type: text/plain; charset="UTF-8" Hi all, The editors met today to process the outstanding issues and PRs. We did not add any new issues to the "Pending Close" state. There are a few PRs now marked "Pending Merge" after the discussion on them has reached rough consensus: Clarify the nature of access requests https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/136 Changed "resource client (RC)" to "client instance" https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 drop "Redirect to a Shortened URL" https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/139 As per our previously established process, these will be merged after 7 days if there are no further comments on the PRs. --- Aaron Parecki https://aaronparecki.com --0000000000006723f705b69a2246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi all,

    The editors met toda= y to process the outstanding issues and PRs. We did not add any new issues = to the "Pending Close" state. There are a few PRs now marked &quo= t;Pending Merge" after the discussion on them has reached rough consen= sus:

    Clarify the nature of access requests
    https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/136

    Changed "resource client (RC)" to "cli= ent instance"

    drop "Redirect to a Sh= ortened URL"

    As per our previously establ= ished process, these will be merged after 7 days if there are no further co= mments on the PRs.

    ---=
    Aaron Parecki


    <= /div>
    --0000000000006723f705b69a2246-- From nobody Thu Dec 17 13:48:52 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CAE3A104D for ; Thu, 17 Dec 2020 13:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pszvHGYt5CcO for ; Thu, 17 Dec 2020 13:48:48 -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 EEEE93A104B for ; Thu, 17 Dec 2020 13:48:47 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BHLmjwu005466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 17 Dec 2020 16:48:46 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_6D5DAD60-A70A-47D2-85F6-0262469A794C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Thu, 17 Dec 2020 16:48:45 -0500 To: txauth gnap X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [GNAP] Build Previews on GitHub 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, 17 Dec 2020 21:48:50 -0000 --Apple-Mail=_6D5DAD60-A70A-47D2-85F6-0262469A794C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Based on community feedback, the editors have deployed some tools to = augment the GitHub repository and increase its usefulness to the working = group. First, we=E2=80=99ve set up a few checks to make sure that branches are = properly tagged and reviewed before a pull request is merged. While no = system is perfect, this should add at least one extra layer of sanity = check. Second, we=E2=80=99ve set up some automated systems so that the document = is automatically built from the =E2=80=9Cmain=E2=80=9D branch whenever a = new commit is pushed there. In addition, a rendered version of the = current state of the repository should always be available at = https://gnap-core-protocol-editors-draft.netlify.app/ = as long as it is = building successfully. Furthermore, all future pull requests will now be automatically rendered = as well. This feature has two purposes: it makes sure a commit doesn=E2=80= =99t break the rendering toolchain (a failure will show up on the PR), = and it also automatically makes the a rendered version of the changes in = the pull request available on a draft URL. For example, the PR that = added this functionality is here: https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/151 = On that pull request, you=E2=80=99ll see a comment from the = =E2=80=9Cgithub-actions" bot with a URL link. This unique URL hosts a = copy of the document including all changes in the pull request.=20 IMPORTANT NOTE: All of these automatically deployed documents are = provided as a convenience and are not official working group drafts. The = only official drafts are those published in the IETF tool suite, = available from the DataTracker page: = https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ = In particular, this means that: 1) The editors=E2=80=99 draft preview is not the working group document, = but it is the current state of the document in between published = revisions. 2) The automatically generated editors=E2=80=99 draft, and the pull = request previews in particular, should not be linked or referenced = externally. These URLs could change or disappear at any time, without = warning, for any reason. They are not intended to be archival, and the = canonical copy of the current editors=E2=80=99 draft will always be the = source document in the repository=E2=80=99s =E2=80=9Cmain=E2=80=9D = branch itself. As always, the document can be rendered directly by downloading the = repository and following the build instructions in the README.md file.=20= Thank you all, =E2=80=94 Justin, Aaron, and Fabien= --Apple-Mail=_6D5DAD60-A70A-47D2-85F6-0262469A794C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Based= on community feedback, the editors have deployed some tools to augment = the GitHub repository and increase its usefulness to the working = group.

    First, = we=E2=80=99ve set up a few checks to make sure that branches are = properly tagged and reviewed before a pull request is merged. While no = system is perfect, this should add at least one extra layer of sanity = check.

    Second, we=E2=80=99ve set up some automated systems so that = the document is automatically built from the =E2=80=9Cmain=E2=80=9D = branch whenever a new commit is pushed there. In addition, a rendered = version of the current state of the repository should always be = available at https://gnap-core-protocol-editors-draft.netlify.app/ = as long as it is building successfully.

    Furthermore, all future pull requests = will now be automatically rendered as well. This feature has two = purposes: it makes sure a commit doesn=E2=80=99t break the rendering = toolchain (a failure will show up on the PR), and it also automatically = makes the a rendered version of the changes in the pull request = available on a draft URL. For example, the PR that added this = functionality is here:

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

    On that pull = request, you=E2=80=99ll see a comment from the =E2=80=9Cgithub-actions" = bot with a URL link. This unique URL hosts a copy of the document = including all changes in the pull request. 

    IMPORTANT NOTE: All = of these automatically deployed documents are provided as a convenience = and are not official working group drafts. The only = official drafts are those published in the IETF tool suite, available = from the DataTracker page: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/=

    In = particular, this means that:

    1) The editors=E2=80=99 draft preview = is not the working group document, but it is the current state of the = document in between published revisions.

    2) The automatically generated = editors=E2=80=99 draft, and the pull request previews in particular, = should not be linked or referenced externally. These URLs could change = or disappear at any time, without warning, for any reason. They are not = intended to be archival, and the canonical copy of the current = editors=E2=80=99 draft will always be the source document in the = repository=E2=80=99s =E2=80=9Cmain=E2=80=9D branch itself.


    As always, the document can be rendered directly by = downloading the repository and following the build instructions in the = README.md file. 

    Thank you all,

     =E2=80=94 Justin, Aaron, and = Fabien
    = --Apple-Mail=_6D5DAD60-A70A-47D2-85F6-0262469A794C-- From nobody Fri Dec 18 00:15:37 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98FA3A1141 for ; Fri, 18 Dec 2020 00:15: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 (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWXdpV1UG9AR for ; Fri, 18 Dec 2020 00:15:33 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 7A35D3A1140 for ; Fri, 18 Dec 2020 00:15:33 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id b9so1980711ejy.0 for ; Fri, 18 Dec 2020 00:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dVYVzCh7T7uquMkR8LCcchf8JkW8UwIhO41QA9uvAZI=; b=duQSwsvFlAqXTql8v4C9rnBvuAoLfjLvoEev4oq0DYd5YOdc8nYWaKyWk6QyWNBf7v hZPUYX4BitftjRQqZ9Z2B4PclQ8m3tVjwX4ERwoVmCsNR50Ns10ERylY9vS06eJJkrew fuO2VA6d5kraoyt60dwg5qMUz3Hs2TOgqTSc0= 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=dVYVzCh7T7uquMkR8LCcchf8JkW8UwIhO41QA9uvAZI=; b=RyK6Vvk575Xd8ZCqgD+wJuFjBu0Xg0FnktMnYH/FYJVuQH84weTBW4jTKshAPfLQsl pVCzmzlFyNYoHIzPKujjoSLw7rYVovmqAA9euA304/ex5ncm9zV+ZH97gLaUBsWZUfpF VUbpJwPA60P8cELDteJs7fQDJGztUjUUJTW28AdQVWoYY9PGuujrHdxu8RQvlC95lGhQ WW9mM7Br8xUDLdzDJHu3ojuQdRwbb0Whye3dHPYUbHnIQV0M3odwLzrI8bZNUzxfdXx0 5thnIVs4hxAhDUAiwg49Dew+SOxlcrF9Vj016fDYh4q8W5PKzKWcCptBFffmU9LvtqyD sn6Q== X-Gm-Message-State: AOAM533ykgs+tgXcKHeFtUKH4D/EbVReezPCdPgXF9Rl+Id1LQD7ugAl rL06GeJpB3/jnNrcpHg0nRSt1h3Q2eHhuCmBLEbgMH7EtC87BBdgKdEPHpFIrxqAMgLO4CJ5+a6 XINVWjN0ye+dX7lc= X-Google-Smtp-Source: ABdhPJzPLaPFPOvSBFLDwD990kdCmRIN+dmDg2ilaTpw0slEQjecDEwv/UM2GAEFrPaQqd4b/yWUjWZrirh/mbgr98Q= X-Received: by 2002:a17:906:8594:: with SMTP id v20mr2811279ejx.470.1608279331620; Fri, 18 Dec 2020 00:15:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Tonge Date: Fri, 18 Dec 2020 09:15:20 +0100 Message-ID: To: Justin Richer Cc: txauth gnap Content-Type: multipart/alternative; boundary="00000000000042eec305b6b8b698" Archived-At: Subject: Re: [GNAP] Build Previews on GitHub 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, 18 Dec 2020 08:15:36 -0000 --00000000000042eec305b6b8b698 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you editors, this is very helpful and hopefully can be a model for standards development wider than this WG. On Thu, 17 Dec 2020 at 22:48, Justin Richer wrote: > Based on community feedback, the editors have deployed some tools to > augment the GitHub repository and increase its usefulness to the working > group. > > First, we=E2=80=99ve set up a few checks to make sure that branches are p= roperly > tagged and reviewed before a pull request is merged. While no system is > perfect, this should add at least one extra layer of sanity check. > > Second, we=E2=80=99ve set up some automated systems so that the document = is > automatically built from the =E2=80=9Cmain=E2=80=9D branch whenever a new= commit is pushed > there. In addition, a rendered version of the current state of the > repository should always be available at > https://gnap-core-protocol-editors-draft.netlify.app/ as long as it is > building successfully. > > Furthermore, all future pull requests will now be automatically rendered > as well. This feature has two purposes: it makes sure a commit doesn=E2= =80=99t > break the rendering toolchain (a failure will show up on the PR), and it > also automatically makes the a rendered version of the changes in the pul= l > request available on a draft URL. For example, the PR that added this > functionality is here: > > https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/151 > > On that pull request, you=E2=80=99ll see a comment from the =E2=80=9Cgith= ub-actions" bot > with a URL link. This unique URL hosts a copy of the document including a= ll > changes in the pull request. > > *IMPORTANT NOTE*: All of these automatically deployed documents are > provided as a convenience and *are not official working group drafts*. > The only official drafts are those published in the IETF tool suite, > available from the DataTracker page: > https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ > > In particular, this means that: > > 1) The editors=E2=80=99 draft preview is not the working group document, = but it is > the current state of the document in between published revisions. > > 2) The automatically generated editors=E2=80=99 draft, and the pull reque= st > previews in particular, should not be linked or referenced externally. > These URLs could change or disappear at any time, without warning, for an= y > reason. They are not intended to be archival, and the canonical copy of t= he > current editors=E2=80=99 draft will always be the source document in the > repository=E2=80=99s =E2=80=9Cmain=E2=80=9D branch itself. > > > As always, the document can be rendered directly by downloading the > repository and following the build instructions in the README.md file. > > Thank you all, > > =E2=80=94 Justin, Aaron, and Fabien > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Dave Tonge --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --00000000000042eec305b6b8b698 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thank you editors, this=C2=A0is very help= ful and hopefully can be a model for standards development wider than this = WG.

    On Thu, 17 Dec 2020 at 22:48, Justin Richer <jricher@mit.edu> wrote:
    = Based on community feedback, the editors have deployed some tools to augmen= t the GitHub repository and increase its usefulness to the working group.
    First, we=E2=80=99ve set up a few checks to make sure tha= t branches are properly tagged and reviewed before a pull request is merged= . While no system is perfect, this should add at least one extra layer of s= anity check.

    Second, we=E2=80=99ve set up some autom= ated systems so that the document is automatically built from the =E2=80=9C= main=E2=80=9D branch whenever a new commit is pushed there. In addition, a = rendered version of the current state of the repository should always be av= ailable at=C2=A0https://gnap-core-protocol-editors-draft.netlify.a= pp/=C2=A0as long as it is building successfully.

    Furthermore, all future pull requests will now be automatically rendered= as well. This feature has two purposes: it makes sure a commit doesn=E2=80= =99t break the rendering toolchain (a failure will show up on the PR), and = it also automatically makes the a rendered version of the changes in the pu= ll request available on a draft URL. For example, the PR that added this fu= nctionality is here:


    = On that pull request, you=E2=80=99ll see a comment from the =E2=80=9Cgithub= -actions" bot with a URL link. This unique URL hosts a copy of the doc= ument including all changes in the pull request.=C2=A0

    =
    IMPORTANT NOTE: All of these automatically deployed documents a= re provided as a convenience and are not official working group drafts. The only official drafts are those published in the IETF tool suite, av= ailable from the DataTracker page:=C2=A0https://datatrac= ker.ietf.org/doc/draft-ietf-gnap-core-protocol/

    In particular, this means that:

    1) The editors= =E2=80=99 draft preview is not the working group document, but it is the cu= rrent state of the document in between published revisions.

    <= /div>
    2) The automatically generated editors=E2=80=99 draft, and the pu= ll request previews in particular, should not be linked or referenced exter= nally. These URLs could change or disappear at any time, without warning, f= or any reason. They are not intended to be archival, and the canonical copy= of the current editors=E2=80=99 draft will always be the source document i= n the repository=E2=80=99s =E2=80=9Cmain=E2=80=9D branch itself.
    =

    As always, the document can be rendered direc= tly by downloading the repository and following the build instructions in t= he README.md file.=C2=A0

    Thank you all,
    =
    =C2=A0=E2=80=94 Justin, Aaron, and Fabien
    -= -
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


    --
    Dave Tonge

    <= /div>

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

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


    --00000000000042eec305b6b8b698-- From nobody Fri Dec 18 06:38:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70C63A074E for ; Fri, 18 Dec 2020 06:38:40 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=securekey.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 mPv4lSym0qw2 for ; Fri, 18 Dec 2020 06:38:34 -0800 (PST) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660118.outbound.protection.outlook.com [40.107.66.118]) (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 64E613A061B for ; Fri, 18 Dec 2020 06:38:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VJ6ggpad+XL4LdUIuMehhRYO3yMBXqteEMdi0tJ2uMtPiZnCvv3wZJNj+wywhUugtRtDybrdn6cAt1BByo1Kiu9cv7rg2/gT7kEHZ/mwj/LDLZhUeqkZolBcnHc9nVVeGI99jiJlsNHN+r0pO4esLUAFZEr+I/m/F9d8UdR+i29eX0DzQkv+ESwzf0y3xMkDamcr1d2qU7WwUKCkyLii/HOuE4MGbHGPP8VlbUkw7K1yLTWuRHPhEIBrxCeyUEH1e+dBkSRWz1bQR7Ie6ftvio08sCmYBQrjSzDUUrbK3b2JtOLIIedVcoum4FErtolHTgRHykIqxx82TQUESs/eTg== 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=CJjP2Ng443iPqj60/tp8fI/GU3bKnZ05cqGTomIgSnA=; b=lY/yD6BtKFsGRrKyRhLAGAxQct4c9s4h09vCIR0BWjcu88hNBX1gZ4YYZIL9nAdXxeDZhj1pfiIHSFrAh520bzNsRCLTsB1KzlpJ6mit+q1h0kTxXFsFZHbOT80x/8VKdE3zOufJXi3Nz5qS3FkafFtvWYsd47ADiiQWl3kALRMQcKXFuJZ9pexWxBBuHOae4vSxhsNfjbLZgJFBs5cIY95wXLzk/E6iR+OvQqVshG+MsYxZGcQN0t1VMiwtb52TUrrCjb1AsDgTswVWWfy7jvs/IZ3haBvCkwr3Se/L7S1Lq2bV/AYqIWgf7d/JMQGxj1nV9P8nPjGgw0HSTGsarw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=securekey.com; dmarc=pass action=none header.from=securekey.com; dkim=pass header.d=securekey.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekey.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CJjP2Ng443iPqj60/tp8fI/GU3bKnZ05cqGTomIgSnA=; b=fvq+J9reniucq0R8wPB2tgeL86go9Oloke1MmFz7TzWGnvTjhI4z4HusmfM67Aeri+YsRv/a44TGHiUF4n8guL+F6pgB+d8YywYG6Jzq/lUwqjeFVD3OQnHB0dWK1FDwsT4guY750Yf7pTk0sAngGCwLxWVJuEv5faxhSCPWUSI= Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:8::32) by YTOPR0101MB1769.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:1c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Fri, 18 Dec 2020 14:38:29 +0000 Received: from YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::bd7a:c0ae:fc2f:18c3]) by YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM ([fe80::bd7a:c0ae:fc2f:18c3%6]) with mapi id 15.20.3654.025; Fri, 18 Dec 2020 14:38:29 +0000 From: Mike Varley To: Aaron Parecki , Justin Richer CC: Dave Tonge , txauth gnap , Steve Moore , Fabien Imbault , Torsten Lodderstedt , Dick Hardt Thread-Topic: [GNAP] Consensus Call on Continuation Request Thread-Index: AQHWzwxy2Pm2ViAgrE2iMeBcujH16anwwWgAgAFu/QCAACKrgIAAIT8AgAAIogCAAAW2gIAAC4GAgAAmYYCAAAacAIAABYYAgACFqQCAAAkwgIAEkQeAgAAFwACAABAZgIAAETcAgAAb5wCAABzhAIAAFaaAgAALFoCAAE5ygIAAHuAAgACpuYCAABJ7AIAAFvMAgABo2QCAAudWyQ== Date: Fri, 18 Dec 2020 14:38:29 +0000 Message-ID: References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> <86771CAF-A62A-4E12-99B5-D1D42BB95B11@mit.edu> <9CA7546C-9A07-4F2D-9A1F-4755BDD3D1C9@mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: parecki.com; dkim=none (message not signed) header.d=none;parecki.com; dmarc=none action=none header.from=securekey.com; x-originating-ip: [184.147.92.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0882bd8c-5764-4446-0ae4-08d8a3629619 x-ms-traffictypediagnostic: YTOPR0101MB1769: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: INno0AXG/jCAUVt+60t+mZBhyaYVGp4bvUgiI47NssXeui5uvRj6UppMI/MBtUor1xs31orrBRWYmxOCPsXh690zY84jCl9IHqtdq5LZo7xyYiHrchKw7/f04CmqVJP21cqsW/PxurHSaVkNMF7e2gfuvfF5a9h8HNhC2vhNKYII6Pa6jT4daO/mQwELVwlcDWVunH7zLZGAFfGSJS3ayQUmShEOTPwAZiajz/leN2YgTKramUHt3g1oe1CSQ5WAvwniUOP02ci5uadDzsvfmZL1fyDM8kUnl3y0UOPNgRvz51LcLlskpKSzAbsGbmZC/oDUMdmztpGYYkua0VspTR6Oxsp04sdfBWoNvmo/lso2qTPmMQPbTyD/r59SUKUdWmpKmvKDlKWkFJdE7r+Qyx6rhS16MB4Zsl1o+ZVMRzKUVg+m46vL8zUR2FqKGx8iTokRH1g9vA6vr4Oan5wMk3Un880doamCzgd3YO/OjwQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39840400004)(366004)(346002)(376002)(136003)(186003)(52536014)(966005)(83380400001)(2906002)(7696005)(316002)(76116006)(110136005)(30864003)(71200400001)(5660300002)(44832011)(6506007)(66446008)(26005)(33656002)(66476007)(54906003)(66946007)(9686003)(66556008)(478600001)(64756008)(8676002)(55016002)(4326008)(8936002)(166002)(83080400002)(86362001)(66574015)(53546011)(16940595002)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?mM3kdbBWcfVttxhE4xVKzAab9hx+RQh4dolz5hF46655UAe/DPMtSCCB?= =?Windows-1252?Q?SunsZSibrYxzYDVNWsYgFWJB+hqYR4VW3Lk1yfAO5yHmsxwpJa6urr+6?= =?Windows-1252?Q?DdoMZC+UlhE3qe57hsVSIGLgeenv1SrJ3ZHWOYM2n1nT4XHZGpeehx7u?= =?Windows-1252?Q?nrTHRNLZf2+3liVHsxNOJ/8eI7X9GF+wryHWHwrSB55EqUZUM+HsczJo?= =?Windows-1252?Q?E6g/eqM1TEfH6LYUm4H2Wl87Nl+UulbmvldnRauRTwCmkvy1Xdf6zYeU?= =?Windows-1252?Q?9VD4JZB1xEWATbj1JVhaIaSCR1E6Rid0QwKE2cSoto1q3ejnALd1SPPx?= =?Windows-1252?Q?uZuTry02YEuQPeUSH6tBF7DQb5+98vLY5tDM5AfoeRu5eZLnpWaHM9YQ?= =?Windows-1252?Q?/XuDUVLNtnvfZL3TR7/wLV7mnf4ZrUAG5FO1hbLHC2b7ka7TdT792qw9?= =?Windows-1252?Q?Brcg/AuCmf80YkAGcvEYj/0N2LNQHhG7xfDELESjzTeH9F/5u7CMeun8?= =?Windows-1252?Q?b+gXaklDBKGwflRxvrPWboshF4Rikzbws4cImKfnRrExCD+s8/fpz5NT?= =?Windows-1252?Q?r9/rO2NP/RAC1L/gz4XicXRkak/Y8k9qMAScPPIWgKXxnajVUj7ezkBN?= =?Windows-1252?Q?U8aANokHKKJvO6FeJl0GLUF1OLVtxze+xdYBIGMYXbHTiU+oXGtpzAUI?= =?Windows-1252?Q?fifAsCnDRZfMrVhz8z7vhOx9Q0ZHj31jyIkjW6DtJeXDXTT1DOmwUJsP?= =?Windows-1252?Q?gjxLqVLegvILVVRYbjAwjERoc/Ts2PbQZ19jnR4SPvpYxS+JZc96D9Jm?= =?Windows-1252?Q?6NBiE3iFAbP4HOIiHOZXZCxD1UPd0rWAYtGxHvDp9qmV7vzha5XIQ9zg?= =?Windows-1252?Q?Us9JQWY9ND7wBLx5Ihy5FjywYmayva3XFHWU3xaMfBbDdajwH24+605H?= =?Windows-1252?Q?iPPLcMEz+dSnHjDXzKMOmwd3A636lhFNit+nx8baerwTgFGkCjzPzTWZ?= =?Windows-1252?Q?bHmgDohA6JIJ4G/JN1olpElGJOvSZZQm5EE52vP7kLbp61XoFZEPq2op?= =?Windows-1252?Q?jS0/mQD5h2YgUm0t?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_YT1PR01MB3099D7C50B13766A7347B542E4C30YT1PR01MB3099CANP_" MIME-Version: 1.0 X-OriginatorOrg: securekey.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT1PR01MB3099.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0882bd8c-5764-4446-0ae4-08d8a3629619 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2020 14:38:29.2161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0k9M8VwBm8eaSAYCcXvcUeYgIOjenMZIn0Q1zd0zCfcBPnyx1e1oXmmeLHCpMstyxj0otyyNbgRyvD69BiLtdz+VcsNNK4J1hNRI/peIUWI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1769 Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 18 Dec 2020 14:38:41 -0000 --_000_YT1PR01MB3099D7C50B13766A7347B542E4C30YT1PR01MB3099CANP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Apologies for being late to the conversation =96 and I see the discussion h= as sparked off other topics, but I just wanted to add my support (+1) for t= he access token requirement for the AS continuation API endpoint. I=92ll admit I struggled with why this needed to be a hard MUST and could n= ot remain optional; although there are a broader range of deployment use ca= ses that are supported with the concept of an access token (distributed AS = systems, for example) why make it a _requirement_? But I am supportive of t= he requirement for the following reasons: 1. Optional spec requirements lead to interop challenges, as implementat= ions usually cover the MUSTS and leave the =91rest for later=92 =96 so when= a system is designed using the options, finding supporting libraries and p= roducts is a challenge to interop and deployment. And I agree with the gith= ub remark on the issue of either it is important enough to be a requirement= and we can justify it, or it should be removed. 2. In recent systems SK has worked with where there is a GNAP-like proto= col, being able to provide a Client with a context specific access_token fo= r the =91continuation=92 api calls =96 linking those tokens to a session at= the AS beyond a cookie or =91txn_id=92 =96 would make the API more consist= ent for the Client for when access_tokens are required for other parts of t= he protocol. Even in situations where our AS was just performing an authent= ication (and not returning claims beyond the authN activity) the access tok= en makes sense; we would have access_tokens for =91live session API calls= =92 and rely on client-credentials for broader scope, non-session bound AP= I calls. 3. Having the capability for the AS to leverage access_tokens (instead o= f just client credentials) enables =96 but does not require =96 a more dive= rse range of distributed system/decoupled scenarios. For example, one could= design a system where there is a loose consortium of AS providers controll= ing access to an individual=92s personal data provider of choice, and the a= ccess_tokens allow these AS to transfer session control between them. This = is great but _even in the case where this nonsense is not required_ having = a single implementation pattern for a Client is crucial for interopetabilit= y, and I believe this access_token requirement does not introduce over comp= lexity to support. Thanks, MV From: TXAuth Date: Wednesday, December 16, 2020 at 12:53 PM To: Justin Richer Cc: Dave Tonge , txauth gnap , St= eve Moore , Fabien Imbault , T= orsten Lodderstedt , Dick Hardt Subject: Re: [GNAP] Consensus Call on Continuation Request CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you recognize the sender and know the c= ontent is safe. This has been a great discussion, and we've opened three new issues to trac= k things that came up in this thread that follow on from the changes in the= PR: * persistent grant identifier https://github.com/ietf-wg-gnap/gnap-core-pro= tocol/issues/146 * rotation of tokens related to continuation request https://github.com/iet= f-wg-gnap/gnap-core-protocol/issues/147 * special label for access token used for continuation https://github.com/i= etf-wg-gnap/gnap-core-protocol/issues/149 The editors believe the specifics in this PR have rough consensus, so we're= going ahead with merging it. Aaron On Wed, Dec 16, 2020 at 3:37 AM Justin Richer > wrote: On Dec 16, 2020, at 5:15 AM, Warren Parad > wrote: #4 is a prereq for this discussion though. If the token is the identifier o= f the grant then it must be in the url to avoid the problem of arbitrary ur= l construction. Of course the uri would be https://as/grants/{grantIdentifi= er}. And this is actually independ= ent of whether or not the token gets rotated. That=92s not true: the identifier exposed to the client for some purpose li= ke grant extension doesn=92t have to be the same identifier that the AS use= s for management. The latter is internal, and exposing internal state to th= e protocol shouldn=92t be a requirement to the pattern. #3 The idea of a dynamic environment is important here, however the argumen= t doesn't justify having this being the same endpoint. Nothing stops us fro= m having two endpoints, one that requests an access token separate from the= ones that manage the grant resource. Nobody said this has to be the same endpoint. In fact, this structure is be= ing put in place to allow them to be separate endpoints. My original design= in XYZ used a single endpoint and exposed an internal identifier of the on= going grant request to the client within the protocol (the transaction hand= le). Changing this to a properly abstracted and protected API pattern allow= s much greater flexibility. The AS now has the choice of how it wants to ma= nage its own dispatching, without the client needing to be aware of any of = it since the client always does the same thing. =97 Justin [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW5= 6Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9= GCeBRRzrSc8kWcUSNtuA] Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Impleme= nt Authress. On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge > wrote: > Dave: which points changed your mind? 1. The issue with re-using client authentication across endpoints in the OA= uth 2 world (token_endpoint_auth_methods_supported, revocation_endpoint_aut= h_methods_supported, introspection_endpoint_auth_methods_supported...) 2. The clear articulation of the 3 different functions of the AS (including= the idea of a self-hosted AS) 3. The aim to support a more dynamic environment where client authenticatio= n only happens in the first interaction between the RC and the AS 4. The agreement that there should be further discussion on whether this ac= cess token should be rotated, and whether it should be an identifier of the= grant. On Wed, 16 Dec 2020 at 00:02, Dick Hardt > wrote: Dave: which points changed your mind? On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge > wrote: Thanks for the detailed response. I think you make the points well and I'm now in favour of the PR. However I do think that to keep the consistency that keeps being discussed,= that the tokens shouldn't be rotated. I also think it would be good to have a discussion about "grant management"= and identifiers for a grant. Dave On Tue, 15 Dec 2020 at 17:30, Justin Richer > wrote: On Dec 15, 2020, at 10:50 AM, Dave Tonge > wrote: > The access token pattern has a lot of benefits, otherwise we wouldn=92t h= ave an entire OAuth ecosystem based on it But what are the benefits in this particular use case? The continuation API= is not like any other API - it is integral to the AS. There are quite a fe= w extensions to OAuth that use client authentication rather than access tok= ens. Yes, and the propagation of that has lead to a mess in the OAuth world. You= =92ve got re-definitions of client authentications at all different endpoin= ts, they=92re technically allowed to vary between endpoints (though I don= =92t know of it happening in practice, that feels like a downgrade attack w= aiting to happen to someone). Then there=92s the fact that all the newest s= ecurity mechanisms we have =97 PKCE, DPoP, and MTLS =97 don=92t rely on cli= ent authentication at all to achieve security. All of these work without th= e client having credentials previously known to the AS, and we already know= that GNAP is going to need to live in this more dynamic world. We need to = think beyond what OAuth 2 has done in the past, and especially from our per= ceptions and assumptions of the models that drive OAuth 2=92s decisions, le= st we repeat its mistakes. Also, I want to challenge this idea of =93integral to the AS=94 as a point.= In OAuth 1, the API was =93integral=94 to the server side, but in OAuth 2 = we split that into the RS concept. Even though in practice, a lot of RS=92s= are still integrated to the AS in some fashion because it=92s a single ser= vice, OAuth 2 is clear about what=92s expected to be known by each componen= t. For the AS as currently defined in GNAP, I=92m seeing three distinct fun= ctions. As per the Terminology discussion, we don=92t have explicit names f= or these yet: - starting a request; this is an endpoint to kick things off; it needs to = be able to look up the rights asked for by the client (if it knows the clie= nt at all ahead of time) and make initial decisions about needed interactio= n and follow up - continuing a request; this is an API that needs to know the context of t= he request itself, including which key it=92s bound to; this is separate fr= om any identity of the client and possibly the user, but an AS implementati= on that has access to those elements can use them - interacting with the user; this is front-facing and in OAuth today is al= ready deployed as a separate service in some places, we should embrace that= at the very least (but doing so formally is a separate issue) Why separate these in this way? There is immense power in having a single c= onsistent way to start the process. The =93continuation API=94 gives us an = HTTP-defined mechanism for managing a request over time, including the simp= le case of returning information from the front channel, but people have al= ready raised the question of non-HTTP and self-hosted AS=92s, which would p= robably want a different kind of continuation API to communicate to the AS.= The same thing with separating out the interaction: there are going to be = a lot of different ways to handle interaction out there, and not all of the= m will be =93integral=94 to the AS in the way that a simple implementation = might do. We=92re defining a protocol based strongly on HTTP and JSON, but = we should structure it in such a way that it can be extended and translated= elsewhere in a clear way. This all raises the question: if we can rely on a unique URL for redirect-b= ased interaction, why not here? The simple reason is that a URL is the :onl= y: mechanism we have in the front channel for passing information, and we n= eed to warn implementors against including sensitive information in it, and= we need to protect it with additional items. We have access to more than j= ust URLs when we=92re dealing with the continuation API, and we ought to ma= ke use of all of our tools in ways that are consistent and make sense. >From a previous email the advantages I see are: - more data can be encoded in a token than in a uri (this seems more of an= edge case) - it can be an identifier for the grant (I don't agree with this) It allows the parts above to live separately, even if they don=92t HAVE to.= And it simplifies what we=92re asking the client to do by making it consis= tent with other parts of the ecosystem. The AS offering an API doesn=92t :h= ave: to be different, and OpenID Connect showed us, with the UserInfo Endpo= int, that that=92s very much the case in practice. Having my client code do very similar things in slightly different ways is = not simpler. Another question I have: do we envisage granting access tokens to the RC th= at will allow it to manage multiple grants? I don=92t see that happening, personally, and it hasn=92t been brought up a= s a use case to date. I also think there will be confusion with the signing being used for differ= ent things. Maybe it just needs to be called out in the spec that: Request 1: signature =3D client authentication Request 2+: signature =3D proof of possession for access token That=92s more or less the intent of what=92s in the specification right now= , and why all the signature methods, which are used for both client auth an= d token possession, are all together in section 8 and not separated by use.= (With the caveat: it=92s only client authentication in the first request = if the AS knows about the client instance ahead of time, which isn=92t alwa= ys going to be true.) That all can likely be made clearer, as is always the= case with spec text. But you can use the signature methods with and withou= t access tokens, and it only gets used without in an initial call where you= don=92t :have: an access token to present. Separating the different kinds of =93client authentication" out in OAuth is= the source of some real confusion. Like right now, what happens if you try= to combine a client assertion, signed request objects for PAR, and DPoP pr= oofs, all in a single request? All of these are optional and all of them = =93do client authentication=94 in some arguable fashion. I=92ve worked on s= everal systems and implemented these things, and their interplay is really = confusing to manage and can go sideways really fast. And that=92s just the = work for a single endpoint, this gets repeated for introspection, revocatio= n, CIBA, device, and on. At the end of the day I=92m in favor of giving the client developers a very= clear set of directions on what they need to do and how they need to acces= s things, and treating the continuation as a token-bound API is, to me, the= clearest pattern we can offer for this piece. =97 Justin On Tue, 15 Dec 2020 at 15:33, Justin Richer > wrote: I agree with Fabien that the persistent identifier is a separate issue. The= current spec re-uses the access token for this artifact, but that=92s pote= ntially brittle and could be changed out for something else. There=92s an i= ssue asking for expanding on the use cases for this functionality (which ha= sn=92t been addressed by this PR): https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 A potentially-rotating URI would be just as brittle, and so having a single= codified identifier for this artifact would be useful, but it does assume = some things about the nature of the AS. Every other use the client has to m= anage the ongoing request over time doesn=92t need an explicit identifier. = Just like with OAuth-protected APIs, the server can determine the context n= ot just from the URI but from the rest of the request, including the access= token itself. This is both more common and more powerful than a strict rea= ding of REST designs. It also follows the HATEOS principles as the entire H= TTP request is taken into account, including the access token and signature= portions. I=92ll also point out that the rotation of these credentials is also filed = as a separate issue that=92s not being addressed right now, so we can revis= it that discussion separately: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 As for the name, we could give it a different label. We have this same patt= ern of issuing a resource-specific access token alongside a URL in the Dyna= mic Registration specification, both in OAuth (https://tools.ietf.org/html/= rfc7592#section-3) and OpenID Connect (https://openid.net/specs/openid-conn= ect-registration-1_0.html#RegistrationResponse). Here it=92s called the =93= registration access token=94 =97 but what=92s important there, as it is her= e, is that it=92s not a different kind of artifact that the client now has = to figure out how to use, it=92s an access token plain and simple. In the O= Auth world this is a bearer token, since that=92s what OAuth 2 uses. In the= GNAP world it=92ll be a bound token, as that=92s what we=92re looking to b= uild on. This is also related to another future discussion about responses = tying an access token to a specific API that=92s told to the client, as we = could potentially re-use those components and concepts here as well: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 And finally, no speculation on the complexity is needed: I implemented this= pattern several months ago during the design team discussions when we were= considering this pattern, and the code is all online for people to see. https://github.com/bspk/oauth.xyz-java/ On the AS side, the most interesting code to this discussion is in the Tran= sactionEndpoint class: https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bspk= /oauth/xyz/authserver/endpoint/TransactionEndpoint.java Here, you=92ll see that on initial request, the server looks up the client = to see if it=92s been registered, but after that, it makes sure that the to= ken and key are appropriate for the ongoing request. From the client side i= t=92s even simpler. The client=92s got a small service function to manage t= he different signature methods that are implemented, and all of them can ta= ke in an optional access token: https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bspk= /oauth/xyz/http/SigningRestTemplateService.java The heavy lift is doing the actual signing, and you need that in order to s= tart the process anyway. Managing the access token as an artifact to use at= the API is completely trivial since the client already needs to manage its= own state internally to do any of this. And note that all of this is chang= ed from how it was before: Previously, the XYZ Protocol had used a =93trans= action handle=94 returned by the AS that the client would use to continue t= he request. However, this simple model was limiting, and the design team ad= opted XAuth=92s model of continuation being an API. In doing so, we made it= like all of the other APIs the client is going to call: in the initial sta= te, it doesn=92t have any kind of access rights, it=92s just calling. From = that initial call forward, the AS just needs to know that the token and key= match what it expects. In summary, my views are: - The access token pattern has a lot of benefits, otherwise we wouldn=92t = have an entire OAuth ecosystem based on it - Magic URIs have a lot of drawbacks which are well understood; while they= can be mitigated, they can also be avoided - Continuation is an API, and treating it like the other kinds of API the = client would call makes sense - Calling this by a special name, like =93grant access token=94 or =93cont= inuation access token=94 is fine, but it should function like any other acc= ess token - The heavy lift for clients is on protecting the message cryptographicall= y, which they need to do anyway =97 Justin On Dec 15, 2020, at 7:50 AM, Dave Tonge > wrote: The persistent identifier is not a different issue, the current access toke= n is used to reference an existing grant It may not be more difficult for a client to use an access token at the AS = / RS. But there is definitely an overhead on the client to manage this sepa= rate access token. On Tue, 15 Dec 2020 at 12:10, Fabien Imbault > wrote: I think we always said the access token was different, and handled as a bou= nd token. But it doesn't mean it's more difficult for the client that already needs t= o be able to handle tokens anyway (bearer or not, both cases could occur). = It's mostly consolidating the logic. You're anticipating a lot of issues which have no specific reason to occur,= such as "can't be used with the token management APIs?". The management AP= I is part of the same general flow. Anticipating issues with rotation is useful, but there are also many ways i= t can be hard to manage through a stateful approach too. And fundamentally,= having everything in a common model (both for the internals of the AS and = for the API calls) will help improve by a large margin what is probably the= weakest point in today's infrastructure. But it's early to be definitive a= s to the downstream impact either way. As for a persistent identifier instead of a continuation API, and generally= the end of your message, it's a totally unrelated issue to this PR, so I s= uggest we don't discuss that here, but in a separate issue if needed. Fabien On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge > wrote: So we've established that this is a different access token, that requires d= ifferent handling at the client. So keeping it could cause more confusion? As an RC, I will have to store the continue `uri` as although it could be s= tatic it could also be dynamic. Why do I need to store an access token as w= ell. It brings me no benefit as an RC, in fact it brings more complexity. A= s I will now need to manage multiple types of tokens with different lifecyc= les: Continuation token - can only be used at the continue endpoint (the name of which is confusi= ng as I can use this endpoint to revoke a grant or get metadata on the gran= t). - may be rotated each time it is used, or may not be - provided in the `continue` section of the response - must be sender-constrained - can't be used with the token management APIs? - can be used to identify the grant when making subsequent grants Access token(s) to use at RS - can only be used at the specified RS - may be sender constrained - when used at the RS, will not result in rotation >From my perspective, most use-cases will require the RC to have a persisten= t identifier for the grant. Why not bring this into the protocol and let th= e AS provide this persistent identifier (through the form of the continue u= ri). Using a rotating access token as a persistent identifier doesn't seem = like the right choice. I see no security benefit to having the continuation access token. It doesn= 't matter if the continue uri leaks as it is useless without an accompanyin= g signature, i.e. any security benefit of having an access token is already= provided by having a signature. The only benefits that I can see are: - If the AS wants to be fully stateless, then you can encode more data in = a token than in a uri - If the AS wants to have a static endpoint for CRUD operations on the gra= nt - To allow the AS to identity a previous grant If we dropped the access token for the continue endpoint and rather mandate= d a dynamic uri this would make things conceptually easier to understand, e= asier for the RC to implement, easier to debug and less chance of errors wh= en rotating tokens (i.e. race conditions could be quite likely if the AS al= ways rotates the token) One-off grant with no continuation or ongoing management: RC sends signature and metadata, no `continue` response provided, therefore= no grant management possible Grant with ongoing management RC sends signature and metadata, AS responds with a continue uri that has t= hese purposes: - can be used by the RC to continue/update, read or revoke the grant - can be used by the RC when making a new grant to identify the previous g= rant As an RC the only permanent items I need to store are: - the continue uri associated with the grant - any access tokens I receive for the grant Dave On Tue, 15 Dec 2020 at 10:11, Fabien Imbault > wrote: Hi Torsten, You're right on both accounts. - for the first remark, it fits quite nicely the init request / continuati= on pattern - for the second remark, it is a sort of handle for the continuation reques= t, which will eventually lead to the issuance or refresh of standard access= tokens Having a specific name is a possibility, I actually suggested that too at s= ome point. Fabien On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt > wrote: Hi Fabien, > Am 12.12.2020 um 12:06 schrieb Fabien Imbault >: > > Hi, > > On the contrary your feedback is most welcome. > > It doesn't accept any token, it needs the particular token as described i= n 3.1 and which is not a bearer token (that's what the "key" : true paramet= er is supposed to convey). > > Let us know if you need more clarifications. Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens. Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side. - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens. I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion. best regards, Torsten. > > Best > Fabien > > Le sam. 12 d=E9c. 2020 =E0 11:33, Torsten Lodderstedt > a =E9crit : > Hi all, > > I didn=92t follow GNAP closely so bear with me if me question seems naive= . > > After having skimmed through the current draft and the PR, I=91m not sure= whether the continuation requests accepts any access token issued to the R= C or the particular access token returned in the =84continue=93 element in = section 3.1.. > > Can you please shed some light on this? > > kind regards, > Torsten. > >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault >: >> >> ? >> You're completely right. Allowing the dev to be lazy is a very good thin= g in general, because it's what we know will work :-) >> >> Le sam. 12 d=E9c. 2020 =E0 03:15, Stephen Moore > a =E9crit : >> Hi Fabien, >> >> For #3) Even after I typed out the hypothetical attack, that was sort of= in the back of my mind, it isn't a huge risk there. So I actually agree wi= th Dick there. Something doesn't sit right with me for the unique URL solut= ion, so I don't like it and came up with a hypothetical that seems like it = could be a down side. >> >> I still think the access token model with the signed request is the way = I'd like to go, because again, it's a mechanism I'd be implementing anyway = to talk to any 'normal' resource. The fact is there is _something_ represen= ting context that has to pass back and forth here, whether that is an acces= s token (which I feel like is more flexible for extensions etc), a unique u= rl, or even a cookie sent in the cookie header. So just to re-iterate, I'm = a +1 on this pull request, speaking as a lazy developer ;) >> -steve >> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault > wrote: >> Again speaking in my own name here. >> >> Dick, we know you'd prefer to have a different design, but this PR shoul= dn't be about that. >> >> Back on your 3 items : >> >> 1) yes we could make pre-register mandatory, but we already decided that= wouldn't be how that would work. We have a client instance that allows a m= ore generic and flexible pattern (which BTW also allows what you want) >> >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever tha= t have the tenancy to flame conversations, I suggest we speak in less abstr= act terms and ask ourselves what that means in practice for devs. Stephen a= nd several others (myself included) have expressed that it wouldn't be hard= er to implement, it would even simplify things quite a lot. If you disagree= please send us a code sample to really show that point by example, because= that's really not obvious. >> >> 3) "If someone has the client credentials, they can impersonate the clie= nt, and all bets are off." Are you seriously making this argument? Because = if you have a better proposal than using cryptographic keys, I'm all hears.= You make it look like there's a problem, while in reality we're only relyi= ng on the basic assumption of all modern digital communications. >> >> And more importantly you never responded to the issues of how to avoid t= he security pitfalls of what you proposed. >> >> Fabien >> >> >> Le sam. 12 d=E9c. 2020 =E0 00:35, Dick Hardt > a =E9crit : >> >> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore > wrote: >> But from the spec: >> " >> When sending a non-continuation request to the AS, the RC MUST identify = itself by including the client field of the request... >> ... >> key (object / string) : The public key of the RC to be used in this requ= est as described in {{request-key}}. This field is REQUIRED. >> ... >> " >> So on the initial request, the key will be there. >> >> The client field can be an object or a string. If the client is pre-regi= stered, then a string could be provided instead of an object. >> >> >> If you don't have the access token, then how do you differentiate betwee= n two requests from the same web application by two different users? Is the= web application supposed to have different credentials for every request? >> >> The AS returns a URI for manipulating the request. I would change the sp= ec so that each request would have a unique URI. This is the usually RESTfu= l pattern that the resource (the grant request) has an URI. >> >> >> So in this case, the easy way out is to pass the access token to the cli= ent, who then, as i stated before, treats the continue request as a RS call= (albeit a specialized version of the RS where the RS is the AS) OR to use = the unique URL, >> but that seems open to a brute force attack by a malicious RC. (What wou= ld be the point of that attack, I don't know, I guess if someone had the cl= ient credentials but not any subjects/resources they could try to intercept= the grant via continue... I just don't feel right locking things down to u= nique URLs that way.) >> >> If someone has the client credentials, they can impersonate the client, = and all bets are off. >> >> LOTS of RS servers return a resource specific URL -- my proposal is no d= ifferent. >> >> >> >> -steve >> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt > wrote: >> Hi Stephen >> >> The client is signing the first request. The key *might* be in the body.= The client is signing all the subsequent requests as well. The "access tok= en" is not needed by the client to prove it is authorized as the client is = proving it is the same client again. >> >> In other words, I don't see the need for an access token, so it does not= need to be put in a URL or an auth header. >> >> If a developer really, really wants to hand context back to the client f= or subsequent calls, they can put it in the URL or some other method. Putti= ng it in the HTTP Authorization header is confusing because it is NOT an ac= cess token -- it is the context of the request. >> >> ? >> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore > wrote: >> Even though I've only been lightly following things, I feel the need to = voice my preference as a developer since I will probably someday have to ei= ther write a RC or RS... >> >> The way I see it is the RC makes the initial request to the AS as part o= f this request, it provides it's key in the body... (So no use of the Autho= rization header) >> At this point that request, represented by the continue URL + "Access To= ken", from my lazy developer standpoint, is a Resource Endpoint and Access = Token, and the AS is acting as a specialized RS in this case. >> So my client posts to whatever URL with the 'access token' in the author= ization header, just like acting on any other resource I have a token for. = YES, I get a new token value to use every call, and there is a decision poi= nt of "Do I have another continue, or do I have a real token for the resour= ce..." But the mechanism is the same to me in the client. >> Personally I like that, because if I have an access_token, I already thi= nk "Put it in the auth header." >> >> So my vote would be +1 for the pull request at this time. >> -steve >> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt > wrote: >> inline ... >> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer > wrote: >> Others had already responded to this previous thread, but I wanted to ad= d a couple points to clarify some things. >> >>> 3) What the client has to do with the "access token" is not the same as= access tokens for an RS. The client gets a new "access token" for each gra= nt request, and for each API call to the AS, and the client learns it can n= ot make any more API calls for that specific request when it does not get a= n "access token" back. This is a completely different design pattern than c= alling an RS API with an access token, and is a new design pattern for call= ing APIs. This adds complexity to the client that it would not normally hav= e, and I don't think GNAP is the right place to start a new design pattern. >>> >> >> I=92m not sure what you mean by these being different =97 the whole poin= t of the design is that the client would be doing the same thing with the a= ccess token at the AS that it does with the RS by re-using the access token= structure. Can you please describe what the differences are, apart from th= e rotation? Presentation of the token and signing of the message are identi= cal. >> >> The client is getting the "access token" from its API. It is not using a= n "access_token" in other API calls to the AS. >> >> >> Rotation of the access token and artifacts for ongoing continuation resp= onses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/= gnap-core-protocol/issues/87 >> >> And for what it=92s worth, GNAP is absolutely the right place to have ne= w designs =97 not that this is one. >> >> You are proposing a new way for an API to provide context for subsequent= API calls. Looks out of scope to me. >> >> >>> 4) Clients that only want claims from the AS and no access tokens will = be required to support an API calling mechanism they would not have to supp= ort otherwise. >> >> Correct, but the delta between the calls a client would make with and wi= thout an access token is vanishingly small. The client has to sign the init= ial request in some fashion, and it will sign the continuation request in t= he same exact fashion, but now include an access token in that request. >> >> Per my other point, there is no value to me in my implementations of pas= sing context back and forth between the client and AS -- so it is extra wor= k providing no value. >> >> Also, any client authentication mechanism that wants to use the HTTP Aut= hentication header is precluded from using it. >> >> >> >> Clients making a request to an AS and not getting an access token is a n= ew design pattern. I think it has value and should be included, but OAuth t= oday shows us the immense value of getting access tokens for calling APIs, = and so we shouldn=92t optimize away from that pattern. >> >>> >>> 5) If the AS does not provide an "access token", there is no mechanism = for a client to delete the request, as the client is not allowed to make a = call without an "access token". >> >> More properly, if the AS does not provide a =93continue=94 field then th= e client can=92t delete the request =97 and yes, that=92s intentional. The = AS is telling this client instance that it can=92t do anything else with th= is ongoing request. If the AS wants to allow the client to manage it, it wi= ll include the mechanisms to do so in the =93continue=94 field. >> >> There is nuance in that intention. A related concern is that deleting a = request does not seem like it is a "continue" operation. >> >> >>> >>> 6) There is no standard identifier for the request. Debugging and audit= ing are hampered by the client and AS having no standard way to identifying= a request. While one AS may provide a unique URL for each grant request, a= nother AS may use a persistent "access token" to identify the grant request= , and other ASs may issue a new "access token" on each API call, providing = no persistent identifier for the request. >> >> Debugging and auditing this kind of thing are functions of the AS. How i= s interoperability harmed by different ASs having different methods to iden= tify their internal data elements? The client doesn=92t need any knowledge = of the AS=92s identifiers, it just needs to know the next steps for continu= ing the negotiation. >> >> Debugging between the client and the AS was what I was referring to. How= does a client developer identify the request when communicating to the AS = developer. Seems complicated. >> >> ? >> -- >> TXAuth mailing 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.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txa= uth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJ= JYtSpI -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- Dave Tonge CTO Error! Filename not specified. Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<= https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry= =3Dgmail&source=3Dg> t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 06= 909772 . Moneyhub Financial Technology Limited 2019 =A9 DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 069= 09772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. -- Dave Tonge CTO Error! Filename not specified. Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<= https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry= =3Dgmail&source=3Dg> t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 06= 909772 . Moneyhub Financial Technology Limited 2019 =A9 DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 069= 09772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- Dave Tonge CTO Error! Filename not specified. Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<= https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry= =3Dgmail&source=3Dg> t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 06= 909772 . Moneyhub Financial Technology Limited 2019 =A9 DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 069= 09772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. -- Dave Tonge CTO Error! Filename not specified. Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL<= https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry= =3Dgmail&source=3Dg> t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 06= 909772 . Moneyhub Financial Technology Limited 2019 =A9 DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 069= 09772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. -- Dave Tonge CTO Error! Filename not specified. Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 06= 909772 . Moneyhub Financial Technology Limited 2019 =A9 DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial T= echnology is registered in England & Wales, company registration number 069= 09772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub Enterprise, = Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth This email and any attachments are for the sole use of the intended recipie= nts and may be privileged, confidential or otherwise exempt from disclosure= under law. Any distribution, printing or other use by anyone other than th= e intended recipient is prohibited. If you are not an intended recipient, p= lease contact the sender immediately, and permanently delete this email and= its attachments. --_000_YT1PR01MB3099D7C50B13766A7347B542E4C30YT1PR01MB3099CANP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Apologies for being late to the conversation =96 and= I see the discussion has sparked off other topics, but I just wanted to ad= d my support (+1) for the access token requirement for the AS continuation = API endpoint.

     

    I=92ll admit I struggled with why this needed to be = a hard MUST and could not remain optional; although there are a broader ran= ge of deployment use cases that are supported with the concept of an access= token (distributed AS systems, for example) why make it a _requirement_? But I am supportive of the re= quirement for the following reasons:

     

    1. Optional spec requirements lead to interop challenges, as implementat= ions usually cover the MUSTS and leave the =91rest for later=92 =96 so when= a system is designed using the options, finding supporting libraries and products is a challenge to interop and deployment= . And I agree with the github remark on the issue of either it is important= enough to be a requirement and we can justify it, or it should be removed.=
    2. In recent systems SK has worked with where there is a= GNAP-like protocol, being able to provide a Client with a context specific= access_token for the =91continuation=92 api calls =96 linking those tokens to a session at the AS beyond a cookie or =91txn_id=92 =96 wo= uld make the API more consistent for the Client for when access_tokens are = required for other parts of the protocol. Even in situations where our AS w= as just performing an authentication (and not returning claims beyond the authN activity) the access token makes sen= se; we would have access_tokens for =91live session API calls=92  and = rely on client-credentials for broader scope, non-session bound API calls.
    3. Having the capability for the AS to leverage access_t= okens (instead of just client credentials) enables =96 but does not require= =96 a more diverse range of distributed system/decoupled scenarios. For example, one could design a system where there is a loose c= onsortium of AS providers controlling access to an individual=92s personal = data provider of choice, and the access_tokens allow these AS to transfer s= ession control between them. This is great but _even in the case where this nonsense is not required_= having a single implementation pattern for a Client is crucial for interop= etability, and I believe this access_token requirement does not introduce o= ver complexity to support.

     

    Thanks,

     

    MV      

     

    From: TXAuth <txauth-bounces@ietf.org> Date: Wednesday, December 16, 2020 at 12:53 PM
    To: Justin Richer <jricher@mit.edu>
    Cc: Dave Tonge <dave.tonge@moneyhub.com>, txauth gnap <txau= th@ietf.org>, Steve Moore <srmoore@gmail.com>, Fabien Imbault <= fabien.imbault@gmail.com>, Torsten Lodderstedt <torsten@lodderstedt.n= et>, Dick Hardt <dick.hardt@gmail.com>
    Subject: Re: [GNAP] Consensus Call on Continuation Request

    CAUTION: This email originated from outside of th= e organization. Do not click links or open attachments unless you recognize= the sender and know the content is safe.

     

    This has been a great d= iscussion, and we've opened three new issues to track things that came up i= n this thread that follow on from the changes in the PR:

    * persistent grant identifier https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146
    * rotation of tokens related to continuation request https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147
    * special label for access token used for continuation https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149

    The editors believe the specifics in this PR have rough consensus, so we're= going ahead with merging it.

     

    Aaron

     

     

    On Wed, Dec 16, 2020 at= 3:37 AM Justin Richer <jricher@mit.e= du> wrote:

    On Dec 16, 2020, at 5:1= 5 AM, Warren Parad <wparad@rhosys.ch> wrote:

     

    #4 is a prereq for this discussion though. I= f the token is the identifier of the grant then it must be in the url to av= oid the problem of arbitrary url construction. Of course the uri would be https://as/grants/{grantIdentifier}.= And this is actually independent of whether or not the token gets rotated.=

     

    That=92s not true: the = identifier exposed to the client for some purpose like grant extension does= n=92t have to be the same identifier that the AS uses for management. The l= atter is internal, and exposing internal state to the protocol shouldn=92t be a requirement to the pattern. 



     

    #3 The idea of a dynamic environment is impo= rtant here, however the argument doesn't justify having this being the same= endpoint. Nothing stops us from having two endpoints, one that requests an access token separate from the ones th= at manage the grant resource.

     

    Nobody said this has to= be the same endpoint. In fact, this structure is being put in place to all= ow them to be separate endpoints. My original design in XYZ used a single e= ndpoint and exposed an internal identifier of the ongoing grant request to the client within the protocol (the transa= ction handle). Changing this to a properly abstracted and protected API pat= tern allows much greater flexibility. The AS now has the choice of how it w= ants to manage its own dispatching, without the client needing to be aware of any of it since the client alway= s does the same thing.

     

     =97 Justin

    Warren Parad

    Founder, CTO

    Secure your user data and compl= ete your authorization architecture. Implement Authress= .

     

     

    On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge = <dave.tonge= @moneyhub.com> wrote:

    > <= span style=3D"font-size:9.0pt;font-family:"Arial",sans-serif">Dav= e: which points changed your mind?

     

    1. The issue with re-using client authentication across endpoint= s in the OAuth 2 world (token_endpoint_auth_methods_supported, revocat= ion_endpoint_auth_methods_supported, introspection_endpoint_auth_metho= ds_supported...)

     

    2. The clear articulation of the 3 different functions of the AS= (including the idea of a self-hosted AS)

     

    3. The aim to supp= ort a more dynamic environment where client authentication only happens in = the first interaction between the RC and the AS

     <= /span>

    4. The agreement t= hat there should be further discussion on whether this access token should = be rotated, and whether it should be an identifier of the grant.

     

     

    On Wed, 16 Dec 2020 at 00:02, Dick Hardt <= ;dick.hardt@gmail= .com> wrote:

    Dave: which points changed your mind?

     

    On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge &= lt;dave.tonge@= moneyhub.com> wrote:

    Thanks for the det= ailed response.

     <= /span>

    I think you make t= he points well and I'm now in favour of the PR.

    However I do think= that to keep the consistency that keeps being discussed, that the tokens s= houldn't be rotated. 

     <= /span>

    I also think it wo= uld be good to have a discussion about "grant management" and ide= ntifiers for a grant.

     <= /span>

    Dave

     

    On Tue, 15 Dec 2020 at 17:30, Justin Richer = <jricher@mit.edu> wrote:

    On Dec 15, 2020, at 10:50 AM, Dave Tonge <= ;dave.tonge@mo= neyhub.com> wrote:

     

    > <= span style=3D"font-size:9.0pt;font-family:"Arial",sans-serif">The= access token pattern has a lot of benefits, otherwise we wouldn=92t have an entire OAuth ecosystem based on it

     <= /span>

    But what are the benefits in this pa= rticular use case? The continuation API is not like any other API - it is integral to the AS. There are quite a few extensions to = OAuth that use client authentication rather than access tokens.<= /span>

     

    Yes, and the propagation of that has lead to= a mess in the OAuth world. You=92ve got re-definitions of client authentic= ations at all different endpoints, they=92re technically allowed to vary between endpoints (though I don=92t know of it= happening in practice, that feels like a downgrade attack waiting to happe= n to someone). Then there=92s the fact that all the newest security mechani= sms we have =97 PKCE, DPoP, and MTLS =97 don=92t rely on client authentication at all to achieve security. All of t= hese work without the client having credentials previously known to the AS,= and we already know that GNAP is going to need to live in this more dynami= c world. We need to think beyond what OAuth 2 has done in the past, and especially from our perceptions and assu= mptions of the models that drive OAuth 2=92s decisions, lest we repeat its = mistakes. 

     

    Also, I want to challenge this idea of =93in= tegral to the AS=94 as a point. In OAuth 1, the API was =93integral=94 to t= he server side, but in OAuth 2 we split that into the RS concept. Even though in practice, a lot of RS=92s are still integra= ted to the AS in some fashion because it=92s a single service, OAuth 2 is c= lear about what=92s expected to be known by each component. For the AS as c= urrently defined in GNAP, I=92m seeing three distinct functions. As per the Terminology discussion, we don=92t have exp= licit names for these yet:

     

     - starting a request; this is an endpo= int to kick things off; it needs to be able to look up the rights asked for= by the client (if it knows the client at all ahead of time) and make initial decisions about needed interaction and fol= low up

     - continuing a request; this is an API= that needs to know the context of the request itself, including which key = it=92s bound to; this is separate from any identity of the client and possibly the user, but an AS implementation that has acc= ess to those elements can use them

     - interacting with the user; this is f= ront-facing and in OAuth today is already deployed as a separate service in= some places, we should embrace that at the very least (but doing so formally is a separate issue)

     

    Why separate these in this way? There is imm= ense power in having a single consistent way to start the process. The =93c= ontinuation API=94 gives us an HTTP-defined mechanism for managing a request over time, including the simple case of r= eturning information from the front channel, but people have already raised= the question of non-HTTP and self-hosted AS=92s, which would probably want= a different kind of continuation API to communicate to the AS. The same thing with separating out the inter= action: there are going to be a lot of different ways to handle interaction= out there, and not all of them will be =93integral=94 to the AS in the way= that a simple implementation might do. We=92re defining a protocol based strongly on HTTP and JSON, but we sh= ould structure it in such a way that it can be extended and translated else= where in a clear way.



    This all raises the question: if we can rely= on a unique URL for redirect-based interaction, why not here? The simple r= eason is that a URL is the :only: mechanism we have in the front channel for passing information, and we need to warn = implementors against including sensitive information in it, and we need to = protect it with additional items. We have access to more than just URLs whe= n we=92re dealing with the continuation API, and we ought to make use of all of our tools in ways that are consist= ent and make sense.

     

    From a previous email the advantages I see a= re:

     - more data can be encoded in a token = than in a uri (this seems more of an edge case)

     - it can be an identifier for the gran= t (I don't agree with this)

     

    It allows the parts above to live separately= , even if they don=92t HAVE to. And it simplifies what we=92re asking the c= lient to do by making it consistent with other parts of the ecosystem. The AS offering an API doesn=92t :have: to be diff= erent, and OpenID Connect showed us, with the UserInfo Endpoint, that that= =92s very much the case in practice. 

     

    Having my client code do very similar things= in slightly different ways is not simpler.



     

    Another question I have: do we envis= age granting access tokens to the RC that will allow it to manage multiple = grants?  

     

    I don=92t see that happening, personally, an= d it hasn=92t been brought up as a use case to date. 



     

    I also think there will be confusion with th= e signing being used for different things. Maybe it just needs to be called= out in the spec that:

     

    Request 1: signature =3D client authenticati= on

    Request 2+: signature =3D proof of possessio= n for access token

     

     

    That=92s more or less the intent of what=92s= in the specification right now, and why all the signature methods, which a= re used for both client auth and token possession, are all together in section 8 and not separated by use.  (With the ca= veat: it=92s only client authentication in the first request if the AS know= s about the client instance ahead of time, which isn=92t always going to be= true.) That all can likely be made clearer, as is always the case with spec text. But you can use the signature method= s with and without access tokens, and it only gets used without in an initi= al call where you don=92t :have: an access token to present.

     

    Separating the different kinds of =93client = authentication" out in OAuth is the source of some real confusion. Lik= e right now, what happens if you try to combine a client assertion, signed request objects for PAR, and DPoP proofs, all i= n a single request? All of these are optional and all of them =93do client = authentication=94 in some arguable fashion. I=92ve worked on several system= s and implemented these things, and their interplay is really confusing to manage and can go sideways really fast. A= nd that=92s just the work for a single endpoint, this gets repeated for int= rospection, revocation, CIBA, device, and on.

     

    At the end of the day I=92m in favor of givi= ng the client developers a very clear set of directions on what they need t= o do and how they need to access things, and treating the continuation as a token-bound API is, to me, the clearest= pattern we can offer for this piece.

     

     =97 Justin



     

     

     

     

     

     

     <= /span>

     

    On Tue, 15 Dec 2020 at 15:33, Justin Richer = <jricher@mit.edu> wrote:

    I agree with Fabien that the persistent iden= tifier is a separate issue. The current spec re-uses the access token for t= his artifact, but that=92s potentially brittle and could be changed out for something else. There=92s an issue asking for= expanding on the use cases for this functionality (which hasn=92t been add= ressed by this PR):

     

     

    A potentially-rotating URI would be just as = brittle, and so having a single codified identifier for this artifact would= be useful, but it does assume some things about the nature of the AS. Every other use the client has to manage the o= ngoing request over time doesn=92t need an explicit identifier. Just like w= ith OAuth-protected APIs, the server can determine the context not just fro= m the URI but from the rest of the request, including the access token itself. This is both more common and m= ore powerful than a strict reading of REST designs. It also follows the HAT= EOS principles as the entire HTTP request is taken into account, including = the access token and signature portions. 

     

    I=92ll also point out that the rotation of t= hese credentials is also filed as a separate issue that=92s not being addre= ssed right now, so we can revisit that discussion separately:

     

     

    As for the name, we could give it a differen= t label. We have this same pattern of issuing a resource-specific access to= ken alongside a URL in the Dynamic Registration specification, both in OAuth (https://tools.ietf.org/html/rfc7592#section= -3) and OpenID Connect (https://o= penid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse). Here it=92s called the =93registration access token=94 =97 but what=92s im= portant there, as it is here, is that it=92s not a different kind of artifa= ct that the client now has to figure out how to use, it=92s an access token= plain and simple. In the OAuth world this is a bearer token, since that=92s what OAuth 2 uses. In the GNAP world it=92l= l be a bound token, as that=92s what we=92re looking to build on. This is a= lso related to another future discussion about responses tying an access to= ken to a specific API that=92s told to the client, as we could potentially re-use those components and concepts here = as well:

     

     

    And finally, no speculation on the complexit= y is needed: I implemented this pattern several months ago during the desig= n team discussions when we were considering this pattern, and the code is all online for people to see. 

     

     

    On the AS side, the most interesting code to= this discussion is in the TransactionEndpoint class:

     

     

    Here, you=92ll see that on initial request, = the server looks up the client to see if it=92s been registered, but after = that, it makes sure that the token and key are appropriate for the ongoing request. From the client side it=92s even = simpler. The client=92s got a small service function to manage the differen= t signature methods that are implemented, and all of them can take in an op= tional access token: 

     

     

    The heavy lift is doing the actual signing, = and you need that in order to start the process anyway. Managing the access= token as an artifact to use at the API is completely trivial since the client already needs to manage its own sta= te internally to do any of this. And note that all of this is changed from = how it was before: Previously, the XYZ Protocol had used a =93transaction h= andle=94 returned by the AS that the client would use to continue the request. However, this simple model was l= imiting, and the design team adopted XAuth=92s model of continuation being = an API. In doing so, we made it like all of the other APIs the client is go= ing to call: in the initial state, it doesn=92t have any kind of access rights, it=92s just calling. From tha= t initial call forward, the AS just needs to know that the token and key ma= tch what it expects. 

     

    In summary, my views are:<= /p>

     - The access token pattern has a lot o= f benefits, otherwise we wouldn=92t have an entire OAuth ecosystem based on= it

     - Magic URIs have a lot of drawbacks w= hich are well understood; while they can be mitigated, they can also be avo= ided

     - Continuation is an API, and treating= it like the other kinds of API the client would call makes sense

     - Calling this by a special name, like= =93grant access token=94 or =93continuation access token=94 is fine, but i= t should function like any other access token

     - The heavy lift for clients is on pro= tecting the message cryptographically, which they need to do anyway

     

     =97 Justin

     



    On Dec 15, 2020, at 7:50 AM, Dave Tonge <= dave.tonge@mon= eyhub.com> wrote:

     

    The persistent ide= ntifier is not a different issue, the current access token is used to&= nbsp;reference an existing grant 

     <= /span>

    It may not be more= difficult for a client to use an access token at the AS /= RS. But there is definitely an overhead on the client to mana= ge this separate access token. 

     <= /span>

     <= /span>

     

    On Tue, 15 Dec 2020 at 12:10, Fabien Imbault= <fabien.i= mbault@gmail.com> wrote:

    I think we always said the access token was = different, and handled as a bound token.

     

    But it doesn't mean it's more difficult for = the client that already needs to be able to handle tokens anyway (bearer or= not, both cases could occur). It's mostly consolidating the logic.

     

    You're anticipating a lot of issues which ha= ve no specific reason to occur, such as "can't be used with the token management APIs?". The management API is part = of the same general flow.

    Anticipating issue= s with rotation is useful, but there are also many ways it can be hard to m= anage through a stateful approach too. And fundamentally, having everything in a common model (both for the internals of the AS and = for the API calls) will help improve by a large margin what is probably the= weakest point in today's infrastructure. But it's early to be definitive a= s to the downstream impact either way.   

     

    As for a persisten= t identifier instead of a continuation API, and generally the end of your m= essage, it's a totally unrelated issue to this PR, so I suggest we don't discuss that here, but in a separate issue if needed= .

     

    Fabien

     

    On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge = <dave.tonge= @moneyhub.com> wrote:

    So we've establish= ed that this is a different access token, that requires different handling = at the client. So keeping it could cause more confusion?<= /p>

     <= /span>

    As an RC, I will h= ave to store the continue `uri` as although it could be static it could als= o be dynamic. Why do I need to store an access token as well. It brings me no benefit as an RC, in fact it brings more com= plexity. As I will now need to manage multiple types of tokens with differe= nt lifecycles:

     <= /span>

    Continuation to= ken 

      - can only = be used at the continue endpoint (the name of which is confusing as I can u= se this endpoint to revoke a grant or get metadata on the grant).

     - may be rot= ated each time it is used, or may not be

     - provided i= n the `continue` section of the response

     - must be se= nder-constrained

     - can't be u= sed with the token management APIs?

     - can be use= d to identify the grant when making subsequent grants

     <= /span>

    Access token(s)= to use at RS

      - can only be used at the specified RS

      - may be se= nder constrained

      - when used= at the RS, will not result in rotation

     <= /span>

    From my perspectiv= e, most use-cases will require the RC to have a persistent identifier for t= he grant. Why not bring this into the protocol and let the AS provide this persistent identifier (through the form of the con= tinue uri). Using a rotating access token as a persistent identifier doesn'= t seem like the right choice. 

     <= /span>

    I see no security = benefit to having the continuation access token. It doesn't matter if the c= ontinue uri leaks as it is useless without an accompanying signature, i.e. any security benefit of having an access token is already = provided by having a signature.

     <= /span>

    The only benefits = that I can see are:

     - If the AS = wants to be fully stateless, then you can encode more data in a token than = in a uri

     - If the AS = wants to have a static endpoint for CRUD operations on the grant=

     - To allow t= he AS to identity a previous grant

     <= /span>

    If we dropped the = access token for the continue endpoint and rather mandated a dynamic uri th= is would make things conceptually easier to understand, easier for the RC to implement, easier to debug and less chance of errors = when rotating tokens (i.e. race conditions could be quite likely if the AS = always rotates the token)

     <= /span>

    One-off grant w= ith no continuation or ongoing management:

    RC sends signature= and metadata, no `continue` response provided, therefore no grant manageme= nt possible

     <= /span>

    Grant with ongo= ing management

    RC sends signature= and metadata, AS responds with a continue uri that has these purposes:

     - can be use= d by the RC to continue/update, read or revoke the grant<= /p>

     - can be use= d by the RC when making a new grant to identify the previous grant

     <= /span>

    As an RC the only = permanent items I need to store are:

     - the contin= ue uri associated with the grant

     - any access= tokens I receive for the grant

     <= /span>

    Dave

     

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault= <fabien.i= mbault@gmail.com> wrote:

    Hi Torsten, 

     

    You're right on both accounts. 

    - for the first remark, it fits quite nicely= the init request  / continuation pattern 

    - for the second remark, it is a sort of han= dle for the continuation request, which will eventually lead to the is= suance or refresh of standard access tokens 

     

    Having a specific name is a possibility= , I actually suggested that too at some point. 

     

    Fabien

     

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodd= erstedt <to= rsten@lodderstedt.net> wrote:

    Hi Fabien, 

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    > 
    > Hi,
    > 
    > On the contrary your feedback is most welcome. 
    > 
    > It doesn't accept any token, it needs the particular token as describe= d in 3.1 and which is not a bearer token (that's what the "key" := true parameter is supposed to convey). 
    > 
    > Let us know if you need more clarifications. 

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you:&nbs= p;
    - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens. 

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=  

    best regards,
    Torsten. 


    > 
    > Best
    > Fabien 
    > 
    > Le sam. 12 d=E9c. 2020 =E0 11:33, Torsten Lodderstedt <torsten@lodderstedt.net> a =E9crit :
    > Hi all,
    > 
    > I didn=92t follow GNAP closely so bear with me if me question seems na= ive.
    > 
    > After having skimmed through the current draft and the PR, I=91m not s= ure whether the continuation requests accepts any access token issued to th= e RC or the particular access token returned in the =84continue=93 element = in section 3.1..
    > 
    > Can you please shed some light on this?
    > 
    > kind regards,
    > Torsten.
    > 
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <    fabien.imbault@gmail.com&= gt;:
    >> 
    >>     
    >> You're completely right. Allowing the dev to be lazy is a very goo= d thing in general, because it's what we know will work :-) 
    >> 
    >> Le sam. 12 d=E9c. 2020 =E0 03:15, Stephen Moore <srmoore@gmail.com> a =E9cri= t :
    >> Hi Fabien,
    >> 
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actually ag= ree with Dick there. Something doesn't sit right with me for the unique URL= solution, so I don't like it and came up with a hypothetical that seems like it could be a down side.
    >> 
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be implementing a= nyway to talk to any 'normal' resource. The fact is there is _something_ re= presenting context that has to pass back and forth here, whether that is an access token (which I feel like is more= flexible for extensions etc), a unique url, or even a cookie sent in the c= ookie header. So just to re-iterate, I'm a +1 on this pull request, speakin= g as a lazy developer ;)
    >> -steve
    >> 
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here. 
    >> 
    >> Dick, we know you'd prefer to have a different design, but this PR= shouldn't be about that. 
    >> 
    >> Back on your 3 items :
    >> 
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that allo= ws a more generic and flexible pattern (which BTW also allows what you want= ) 
    >> 
    >> 2) instead of blame arguments of who's less restful/HATEOAS/whatev= er that have the tenancy to flame conversations, I suggest we speak in less= abstract terms and ask ourselves what that means in practice for devs. Ste= phen and several others (myself included) have expressed that it wouldn't be harder to implement, it would even simp= lify things quite a lot. If you disagree please send us a code sample to re= ally show that point by example, because that's really not obvious.  >> 
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in reality we're only relying on the basic assumption of al= l modern digital communications. 
    >>  
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed. 
    >> 
    >> Fabien 
    >> 
    >> 
    >> Le sam. 12 d=E9c. 2020 =E0 00:35, Dick Hardt <dick.hardt@gmail.com> a =E9= crit :
    >> 
    >> 
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.  >> ...
    >> "
    >> So on the initial request, the key will be there. 
    >> 
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>  
    >> 
    >> If you don't have the access token, then how do you differentiate = between two requests from the same web application by two different users? = Is the web application supposed to have different credentials for every req= uest?
    >> 
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >> 
    >>  
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL, 
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone had = the client credentials but not any subjects/resources they could try to int= ercept the grant via continue... I just don't feel right locking things down to unique URLs that way.)
    >> 
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >> 
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >> 
    >> 
    >>  
    >> -steve
    >> 
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >> 
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >> 
    >> In other words, I don't see the need for an access token, so it do= es not need to be put in a URL or an auth header.
    >> 
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >> 
    >>     ᐧ
    >> 
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel the ne= ed to voice my preference as a developer since I will probably someday have= to either write a RC or RS... 
    >> 
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of the= Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a token= for. YES, I get a new token value to use every call, and there is a decisi= on point of "Do I have another continue, or do I have a real token for the resource..." But the mechanism is t= he same to me in the client.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header." 
    >> 
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >> 
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ... 
    >> 
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >> 
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific request when it does not get an "access token" back. Th= is is a completely different design pattern than calling an RS API with an = access token, and is a new design pattern for calling APIs. This adds compl= exity to the client that it would not normally have, and I don't think GNAP is the right place to start a new design patt= ern.
    >>> 
    >> 
    >> I=92m not sure what you mean by these being different =97 the whol= e point of the design is that the client would be doing the same thing with= the access token at the AS that it does with the RS by re-using the access= token structure. Can you please describe what the differences are, apart from the rotation? Presentation of the tok= en and signing of the message are identical.
    >> 
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>  
    >> 
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https= ://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87
    >> 
    >> And for what it=92s worth, GNAP is absolutely the right place to h= ave new designs =97 not that this is one.
    >> 
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>  
    >> 
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise. 
    >> 
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that request. 
    >> 
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >> 
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >> 
    >>  
    >> 
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=92t optimize away from that pattern.
    >> 
    >>> 
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >> 
    >> More properly, if the AS does not provide a =93continue=94 field t= hen the client can=92t delete the request =97 and yes, that=92s intentional= . The AS is telling this client instance that it can=92t do anything else w= ith this ongoing request. If the AS wants to allow the client to manage it, it will include the mechanisms to do so in the = =93continue=94 field.
    >> 
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>  
    >> 
    >>> 
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identify the grant request, and other ASs may issue a new &= quot;access token" on each API call, providing no persistent identifie= r for the request.
    >> 
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=92t need any know= ledge of the AS=92s identifiers, it just needs to know the next steps for continuing the negotiation.
    >> 
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>  
    >>     ᐧ
    >> -- 
    >> TXAuth mailing list
    >> TXAuth@i= etf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    >>     ᐧ
    >> -- 
    >> TXAuth mailing list
    >> TXAuth@i= etf.org
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> -- 
    >> TXAuth mailing list
    >> TXAuth@i= etf.org
    >> https://www.goo= gle.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&source=3Dg= mail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJYtSpI=

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


     

    -- 

    Dave Ton= ge

    CTO

    Moneyhub Fi= nancial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL

    t: = +44 (0)117 280 5120

     = ;

    Moneyhub En= terprise is a trading style of Moneyhub Financial Technology Limited which = is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 80= 9360) at https://register.fca.org.uk/. Moneyhub Financial Technology i= s registered in England & Wales, company registration number  = ;06909772 .

    Moneyhub&nbs= p;Financial Technology Limited 2019 =A9

     =

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised an= d unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts are virus-free, it is the recipient's sole responsibility to scan all at= tachments for viruses. All calls and emails to and from this company may be monitored and recorded for legi= timate purposes relating to this company's business. Any opinions expressed= in this email (or in any attachments) are those of the author and do not n= ecessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.

     

    Moneyhub Enterprise is a tradin= g style of Moneyhub Financial Technology Limited which is authorised and re= gulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Registe= r (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is r= egistered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub E= nterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is conf= idential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst rea= sonable efforts are made to ensure that any attachments are virus-free, it = is the recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorded for legitimate purposes relatin= g to this company's business. Any opinions expressed in this email (or in a= ny attachments) are those of the author and do not necessarily represent th= e opinions of Moneyhub Financial Technology Limited or of any other group company.

     


     

    -- 

    Dave Tong= e

    CTO

    Moneyhub Fin= ancial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL

    t: <= /span>+44 (0)117 280 5120

     =

    Moneyhub Ent= erprise is a trading style of Moneyhub Financial Technology Limited which i= s authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809= 360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number  <= /span>06909772 .

    Moneyhub&nbs= p;Financial Technology Limited 2019 =A9

     =

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised an= d unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts are virus-free, it is the recipient's sole responsibility to scan all at= tachments for viruses. All calls and emails to and from this company may be monitored and recorded for legi= timate purposes relating to this company's business. Any opinions expressed= in this email (or in any attachments) are those of the author and do not n= ecessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.

     

    Moneyhub Enterprise is a tradin= g style of Moneyhub Financial Technology Limited which is authorised and re= gulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Registe= r (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is r= egistered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub E= nterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is conf= idential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst rea= sonable efforts are made to ensure that any attachments are virus-free, it = is the recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorded for legitimate purposes relatin= g to this company's business. Any opinions expressed in this email (or in a= ny attachments) are those of the author and do not necessarily represent th= e opinions of Moneyhub Financial Technology Limited or of any other group company.

     

     

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


     

    -- 

    Dave Tong= e

    CTO

    Moneyhub Fin= ancial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL

    t: <= /span>+44 (0)117 280 5120

     =

    Moneyhub Ent= erprise is a trading style of Moneyhub Financial Technology Limited which i= s authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809= 360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number  <= /span>06909772 .

    Moneyhub&nbs= p;Financial Technology Limited 2019 =A9

     =

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised an= d unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts are virus-free, it is the recipient's sole responsibility to scan all at= tachments for viruses. All calls and emails to and from this company may be monitored and recorded for legi= timate purposes relating to this company's business. Any opinions expressed= in this email (or in any attachments) are those of the author and do not n= ecessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.

     

    Moneyhub Enterprise is a tradin= g style of Moneyhub Financial Technology Limited which is authorised and re= gulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Registe= r (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is r= egistered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub E= nterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is conf= idential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst rea= sonable efforts are made to ensure that any attachments are virus-free, it = is the recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorded for legitimate purposes relatin= g to this company's business. Any opinions expressed in this email (or in a= ny attachments) are those of the author and do not necessarily represent th= e opinions of Moneyhub Financial Technology Limited or of any other group company.

     

     


     

    -- 

    Dave Tong= e

    CTO

    Moneyhub Fin= ancial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL

    t: <= /span>+44 (0)117 280 5120

     =

    Moneyhub Ent= erprise is a trading style of Moneyhub Financial Technology Limited which i= s authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809= 360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number  <= /span>06909772 .

    Moneyhub&nbs= p;Financial Technology Limited 2019 =A9

     =

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised an= d unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts are virus-free, it is the recipient's sole responsibility to scan all at= tachments for viruses. All calls and emails to and from this company may be monitored and recorded for legi= timate purposes relating to this company's business. Any opinions expressed= in this email (or in any attachments) are those of the author and do not n= ecessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.

     

    Moneyhub Enterprise is a tradin= g style of Moneyhub Financial Technology Limited which is authorised and re= gulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Registe= r (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is r= egistered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub E= nterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is conf= idential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst rea= sonable efforts are made to ensure that any attachments are virus-free, it = is the recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorded for legitimate purposes relatin= g to this company's business. Any opinions expressed in this email (or in a= ny attachments) are those of the author and do not necessarily represent th= e opinions of Moneyhub Financial Technology Limited or of any other group company.

     


     

    -- 

    Dave Tong= e

    CTO

    Moneyhub Fin= ancial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL

    t: <= /span>+44 (0)117 280 5120

     =

    Moneyhub Ent= erprise is a trading style of Moneyhub Financial Technology Limited which i= s authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809= 360) at https://register.fca.org.uk/. Moneyhub Financial Technology is = registered in England & Wales, company registration number  <= /span>06909772 .

    Moneyhub&nbs= p;Financial Technology Limited 2019 =A9

     =

    DISCLAIMER: = This email (including any attachments) is subject to copyright, and the inf= ormation in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised an= d unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts are virus-free, it is the recipient's sole responsibility to scan all at= tachments for viruses. All calls and emails to and from this company may be monitored and recorded for legi= timate purposes relating to this company's business. Any opinions expressed= in this email (or in any attachments) are those of the author and do not n= ecessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.

     

    Moneyhub Enterprise is a tradin= g style of Moneyhub Financial Technology Limited which is authorised and re= gulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Registe= r (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is r= egistered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 =A9 Moneyhub E= nterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 

    DISCLAIMER: This email (including = any attachments) is subject to copyright, and the information in it is conf= idential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst rea= sonable efforts are made to ensure that any attachments are virus-free, it = is the recipient's sole responsibility to scan all attachments for viruses.= All calls and emails to and from this company may be monitored and recorded for legitimate purposes relatin= g to this company's business. Any opinions expressed in this email (or in a= ny attachments) are those of the author and do not necessarily represent th= e opinions of Moneyhub Financial Technology Limited or of any other group company.


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

     

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

    This email and any attachments are for the sole use of the intended recipie= nts and may be privileged, confidential or otherwise exempt from disclosure= under law. Any distribution, printing or other use by anyone other than th= e intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediatel= y, and permanently delete this email and its attachments.

    --_000_YT1PR01MB3099D7C50B13766A7347B542E4C30YT1PR01MB3099CANP_-- From nobody Fri Dec 18 08:47:39 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4113A0A71 for ; Fri, 18 Dec 2020 08:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_I6loGL7aYo for ; Fri, 18 Dec 2020 08:47:34 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CADDD3A0A4C for ; Fri, 18 Dec 2020 08:47:33 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d78 with ME id 5snV240025Eqqlm03snVci; Fri, 18 Dec 2020 17:47:30 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 18 Dec 2020 17:47:30 +0100 X-ME-IP: 90.79.54.243 To: txauth gnap From: Denis Message-ID: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> Date: Fri, 18 Dec 2020 17:47:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A4002E4398D757C0A4FC1143" Content-Language: fr Archived-At: Subject: [GNAP] Comments on the GNAP Wiki Terminology 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, 18 Dec 2020 16:47:38 -0000 This is a multi-part message in MIME format. --------------A4002E4398D757C0A4FC1143 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI, the wiki page is there:https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only): https://www.iso.org/obp This may provide some ideas and you will notice that a given term may be used in different ISO standards with a different definition. I have nine comments (each one being numbered). _ 1) Current definition of AS_: The current definition is: *Authorization Server (AS) *      Definition: server that grants privileges to a particular end-user and that provides them to a client in the form of an access token This is fine in general (but see later another comment about it), but the word privileges is left undefined. _ 2) Definition of a privilege__ _ A suggested "privilege" definition has been proposed in the wiki page: "A privilege is the right to perform an operation (or action) on a Resource." See also other def . In the "other def.", the term is considered to be a synonym of a permission. ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :      privilege access right permission authorization to a subject (3.15) to access a resource (3.14) Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request is granted according to its access control policy.                               The access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.) Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation                               that a subject is willing to perform on a resource. (...) I propose the following: *privilege*: right or attribute associated with an end-user with: *right*: ability given to an end-user to perform a given operation on an object under the control of a RS *attribute*: characteristics or property related to an end-user __ _3) Definition of a Client _ The current definition is: *Client *      Definition: application that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs      Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance               (the client software). For some kinds of client software, there could be many instances of a single piece of client software. Example: a client can be a mobile application, a web application, etc. Previously, I proposed: *Client*: application used by an end-user to interact with an AS or a RS The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity. The definition should capture this point. A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "access privileges". The words "a negotiation of" should be deleted. This raises the point where this definition of a "Client" is using the wording "/access privileges/" whereas the definition of an "Authorization Server (AS)" is using the word "/privileges/". We should make both definitions consistent. I have a slight preference for "access privileges", but I could also live with "privileges". Hence my proposals: *     Client *      application /operated/ /by an end-user /that consumes resources from one or several RSs, possibly requiring /access privileges from/ one or several ASs * **    Authorization Server (AS) *      server that grants /access/ privileges to a particular end-user and that provides them to a client in the form of an access token _4) Definition of a Resource Server (RS) _ The current definition is: * **     Resource Server (RS) *      Definition: server that provides operations on /protected /resources; such operations require that the client provides valid access tokens issued by an AS A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources. I propose the following definition while merging the two sentences: *Resource Server (RS) *       server that provides operations on resources /where/ protected operations require that the client provides /one or more/ valid access tokens issued by /one or more ASs/ In theabove modification I added "/one or more /". I am presuming that GNAP will allow the presentation of more that one access token from different ASs in order to allow an end-user to perform one operation on a protected resource. _5) Definition of Resource Owner_ _ _ The current definition is: *Resource Owner (RO) *      Definition: personal or organizational entity that may grant privileges on resources it has authority upon Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules). I don't know what a "personal entity" is but I know what a "natural person" is. Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing. It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:       responsible party for the Resource(s)       Note 1 to entry: The Resource Owner is responsible for granting, denying, and revoking Access to Resource(s).       Note 2 to entry: The responsible Resource Owner is determined by the concrete Resource. I propose: *Resource Owner (RO) * /natural person /or organizational 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) or automatic (i.e. through predefined rules). __ _ 6) Definition of Access Token__ _ The current definition is:      Access token      Definition: digitally signed data that contains specific rights and/or attributes Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed. The AS usually provides a method for the RO to revoke the privileges at any point in time.     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token) The definition is fine, but not the two Notes. The second sentence from the Note 1 is stating: "The AS usually provides a method for the RO to revoke the privileges at any point in time". Revoking "the privileges" is different from revoking an "access token". The second sentence of this Note 1 which is supposed to be about access token is confusing. The privileges may be changed at any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked. Any call-back from a RS to an AS should be avoided in order to respect the user's privacy. Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sentence. Note 2 is stating: Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token) From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed. So my proposal is as follows: *     Access token *      digitally signed data that contains specific rights and/or attributes Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed. __ _ 7) Definition of Grant__ _ The current definition is: *     Grant *      Definition: (verb): to permit, as a privilege given to an end-user to exercise some rights and/or assert attributes during a specific duration Definition: (noun): the act of granting The words ", as a privilege given to" are unnecessary" I propose:      Grant      (verb): to permit an end-user to exercise some rights and/or /to/ assert /some /attributes /at a specific time and /during a specific duration (noun): the act of granting _8) Definition of Resource_ _ _ The current definition is: *     Resource *       Definition: protected API served by a RS and accessed by a client, if and only if a valid access token is provided This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource": *     Protected Resource *      protected API served by a RS and /that can be /accessed by a client, if and only if a valid access token is provided If a definition of a Resource is needed, I propose: *     Resource ** ***public or protected resource from a RS _ 9) Definition of Subject Information _ The current definition is: *Subject Information* Definition: claim asserted locally by an AS about a person, organization or device Source: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP) This is information returned by an AS about an end-user. I would thus simply propose instead: * **     Subject Information *      information returned to a Client by an AS about an end-user Denis --------------A4002E4398D757C0A4FC1143 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    FYI, the wiki page is there:  https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ideas and you will notice that a given term may be used in different ISO standards with a different definition.  

    I have nine comments (each one being numbered).

    1) Current definition of AS    :  

    The current definition is:

         Authorization Server (AS)
         Definition: server that grants privileges to a particular end-user and that provides them to a client in the form of an access token

    This is fine in general (but see later another comment about it), but the word privileges is left undefined.  

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page: "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synonym of a permission.      

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

         privilege  
        access right
        permission
        authorization to a subject (3.15) to access a resource (3.14)

            Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request is granted according to its access control policy.
                                  The access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

            Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
                                  that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

            privilege: right or attribute associated with an end-user

    with:
            right: ability given to an end-user to perform a given operation on an object under the control of a RS

              attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

         Client
         Definition: application that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

         Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
                  (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
            Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
     
              Client: application used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

     
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "access privileges".
    The words "a negotiation of" should be deleted.

    This raises the point where this definition of a "Client" is using the wording     "access privileges" whereas the definition of an "Authorization Server (AS)"
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could also live with "privileges".  

    Hence my proposals:

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

        Authorization Server (AS)
         server that grants access privileges to a particular end-user and that provides them to a client in the form of an access token
     
    4) Definition of a Resource Server (RS)

    The current definition is:

         Resource Server (RS)

         Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


          Resource Server (RS)
          server that provides operations on resources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the  above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
     
    5) Definition of Resource Owner  

    The current definition is:

         Resource Owner (RO)
         Definition: personal or organizational entity that may grant privileges on resources it has authority upon
            Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural person" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

          responsible party for the Resource(s)
          Note 1 to entry: The Resource Owner is responsible for granting, denying, and revoking Access to Resource(s).
          Note 2 to entry: The responsible Resource Owner is determined by the concrete Resource.

    I propose:

         Resource Owner (RO)
         natural person or organizational 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) or automatic (i.e. through predefined rules).


    6) Definition of Access Token      

    The current definition is:

         Access token
         Definition: digitally signed data that contains specific rights and/or attributes
            Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
                    The AS usually provides a method for the RO to revoke the privileges at any point in time.         
        Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from the Note 1 is stating: "The AS usually provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an "access token". The second sentence of this Note 1 which is supposed to be about access token is confusing.
    The privileges may be changed at any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sentence.
    Note 2 is stating:
              Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as follows:

         Access token
         digitally signed data that contains specific rights and/or attributes   
            Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant      

    The current definition is:

         Grant
         Definition: (verb): to permit, as a privilege given to an end-user to exercise some rights and/or assert attributes during a specific duration
            Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

         Grant
         (verb): to permit an end-user to exercise some rights and/or to assert some attributes at a specific time and during a specific duration
            (noun): the act of granting
     
     
    8) Definition of Resource  

    The current definition is:

         Resource
          Definition: protected API served by a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

         Protected Resource
         protected API served by a RS and that can be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

         Resource
         public or protected resource from a RS


    9) Definition of Subject Information

    The current definition is:
     
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propose instead:

         Subject Information
         information returned to a Client by an AS about an end-user
     
    Denis

    --------------A4002E4398D757C0A4FC1143-- From nobody Fri Dec 18 09:02:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BA13A0A50 for ; Fri, 18 Dec 2020 09:02:26 -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 Abt9KY5UgJjN for ; Fri, 18 Dec 2020 09:02:24 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A7C3A0AD3 for ; Fri, 18 Dec 2020 09:02:23 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id q137so2646679iod.9 for ; Fri, 18 Dec 2020 09:02: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=BeHlYYgtIxBNRVw3OnRNpAXn6z29ys0Yf/xUZAYZQ7g=; b=PnUwVgmn/u/3LqtukJzfxJPRfE2wDq8Ru9UPHtZMlSKGH4DcY3kFs3SlUmO9lfjU9R eyKUYcoTG56BhITVE4U5WER1meGmIToa4aHxQ1Uyb66i68B5tr5U90fkrPAoxcBe/MQ/ gES/2pSVp5Iob5rNeBU0rJENE4HWHJHkRnHwOLwV+wOlD4KEhNA/dkMSaeaNAGo4+yhS DuGwl0epFnZLSntvadauhFXNmepLmuh2heeFAAO6MPMJpb0R0K5zfkBZs/zHpovaSV9x X+4Zp2nLJxsfV/JDcf5Ij4Y9T1g1Q2J/Kpo2VS4NFygX8a6WzF8NkjWf3tb2cfjniJGV wAMw== 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=BeHlYYgtIxBNRVw3OnRNpAXn6z29ys0Yf/xUZAYZQ7g=; b=FDnbSEiw33yOWpBEev0773EI+Tg5ldvSuBA7e4ShdgAjjN4irULNZetNGWa55ll8Nu rT//c8d83Szsb7019mgSjdMPLUgiCUkIijPMNj7WRi/y0Bj5qzuZu8Cn5jlgreo4i+3Y 6r+V2VbxmoR/rxItSxL0/E/PxyrERWZCkbikQ+QCDr1At6klQ9c9YsK2xUoJtVd5LH3B NgJis1QFR4erFDT6Yg0XNWfXoMfkuXBG+0ZEjs+uX/KJbeZVgM70dBRITznfDSsqGLjk 8SrnMmUfvMnIZQwDm5sMVwa5eLklXyeN5rQHLPxqGrMlAf35jRAyWyzDPCH2zMzVCrL8 fkwQ== X-Gm-Message-State: AOAM532O9Z1u9o7biP7agSTvwj2mcjjB2tdgaaeBZImEfXSGdEn4uOx1 2xcKXzYUb7RYov1ZYl56VzGDd7eP8rLBtV50KUQ= X-Google-Smtp-Source: ABdhPJyylHCY2gHrIFcVS+a3S15s22qqsbaf3OGEujmbuCQNdYwvL/ML5BwrAO4yCp38Gq01LdoS2FFCrFc2VujGtZY= X-Received: by 2002:a02:4b42:: with SMTP id q63mr4441659jaa.77.1608310942894; Fri, 18 Dec 2020 09:02:22 -0800 (PST) MIME-Version: 1.0 References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> In-Reply-To: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> From: Fabien Imbault Date: Fri, 18 Dec 2020 18:02:09 +0100 Message-ID: To: Denis Cc: txauth gnap Content-Type: multipart/alternative; boundary="0000000000007096e305b6c0122f" Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 18 Dec 2020 17:02:27 -0000 --0000000000007096e305b6c0122f Content-Type: text/plain; charset="UTF-8" Thanks Denis, that's a really useful feedback. I'll review that in more detail, but something that's really not clear to me is the last one, subject information. 1) is it about the end-user ? or the RO ? (as is the current definition in V02) 2) why do we even need to call it subject information ? For instance if it's about the end-user, it should only be end-user information. 3) do we want to use entity or subject in the definitions ? (cf RO for instance). Regarding natural person vs entity we had a discussion on the mailing list previously. Cheers, Fabien On Fri, Dec 18, 2020 at 5:47 PM Denis wrote: > FYI, the wiki page is there: > https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > FYI first, there is a useful web page where you can find all the ISO > definitions as well as the text for any ISO standard (up to its definition > section only): > https://www.iso.org/obp > This may provide some ideas and you will notice that a given term may be > used in different ISO standards with a different definition. > > I have nine comments (each one being numbered). > > * 1) Current definition of AS*: > > The current definition is: > > *Authorization Server (AS) * > Definition: server that grants privileges to a particular end-user > and that provides them to a client in the form of an access token > This is fine in general (but see later another comment about it), but the > word privileges is left undefined. > > * 2) Definition of a privilege* > A suggested "privilege" definition has been proposed in the wiki page: "A > privilege is the right to perform an operation (or action) on a Resource." > See also other def > > . > In the "other def.", the term is considered to be a synonym of a > permission. > > ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following : > > privilege > access right > permission > authorization to a subject (3.15) > to access a resource (3.14) > > > Note 1 to entry: Privilege is a necessary but not sufficient > condition for access. Access occurs when the access request is granted > according to its access control policy. > The access control policy is based on > privileges and may include other environmental factors (e.g. time-of-day, > location, etc.) > > Note 2 to entry: Privileges take the form of data presented by a > subject or obtained for a subject that is used by a Policy Decision Point > in order to grant or deny an operation > that a subject is willing to perform on a > resource. > (...) > I propose the following: > > *privilege*: right or attribute associated with an end-user > with: > *right*: ability given to an end-user to perform a given > operation on an object under the control of a RS > > *attribute*: characteristics or property related to an end-user > > > > *3) Definition of a Client * The current definition is: > *Client * > Definition: application that consumes resources from one or several > RSs, possibly requiring a negotiation of access privileges with one or > several ASs > > Note: this specification differentiates between a specific instance > (the client instance, identified by its public key) and the software > running the instance > (the client software). For some kinds of client software, > there could be many instances of a single piece of client software. > Example: a client can be a mobile application, a web application, etc. > > Previously, I proposed: > > *Client*: application used by an end-user to interact with an AS or > a RS > > The current definition is missing to indicate who is operating the client. > It is an end-user, i.e. it is not another application, nor a process, nor > an entity. > The definition should capture this point. > A second point: the current definition is using the wording "requiring a > negotiation". There is no "negotiation". Either the AS has or has not the > "access privileges". > The words "a negotiation of" should be deleted. > > This raises the point where this definition of a "Client" is using the > wording "*access privileges*" whereas the definition of an "Authorization > Server (AS)" > is using the word "*privileges*". We should make both definitions > consistent. I have a slight preference for "access privileges", but I could > also live with "privileges". > > Hence my proposals: > > * Client * > application *operated* *by an end-user *that consumes resources from > one or several RSs, possibly requiring *access privileges from* one or > several ASs > > * Authorization Server (AS) * > server that grants *access* privileges to a particular end-user and > that provides them to a client in the form of an access token > > > *4) Definition of a Resource Server (RS) * > The current definition is: > > * Resource Server (RS) * > Definition: server that provides operations on *protected *resources; > such operations require that the client provides valid access tokens issued > by an AS > A RS may offer both public resources and protected resources. Valid access > tokens are only needed for protected resources. > I propose the following definition while merging the two sentences: > > *Resource Server (RS) * > server that provides operations on resources *where* protected > operations require that the client provides *one or more* valid access > tokens issued by *one or more ASs* > In the above modification I added "*one or more *". I am presuming that > GNAP will allow the presentation of more that one access token from > different ASs > in order to allow an end-user to perform one operation on a protected > resource. > > *5) Definition of Resource Owner* > > The current definition is: > * Resource Owner (RO) * > Definition: personal or organizational entity that may grant > privileges on resources it has authority upon > Note: the act of granting privileges may be manual (i.e. through an > interaction) or automatic (i.e. through predefined rules). > > I don't know what a "personal entity" is but I know what a "natural > person" is. > > Furthermore, a Resource Owner is not granting privileges (or access > privileges) in the same way an AS is doing. > > It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where > Resource Owner (RO) is defined as: > > responsible party for the Resource(s) > Note 1 to entry: The Resource Owner is responsible for granting, > denying, and revoking Access to Resource(s). > Note 2 to entry: The responsible Resource Owner is determined by the > concrete Resource. > I propose: > *Resource Owner (RO) * > *natural person *or organizational 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) or automatic (i.e. through predefined rules). > > * 6) Definition of Access Token* > The current definition is: > Access token > Definition: digitally signed data that contains specific rights > and/or attributes > Note 1: the access token can be issued to an end-user (usually > requiring his authentication) and subsequently refreshed. > The AS usually provides a method for the RO to revoke the > privileges at any point in time. > Note 2: an access token may act as a capability (i.e. bearer token) > or require an additional authentication by binding to a key (i.e. bound > token) > The definition is fine, but not the two Notes. > The second sentence from the Note 1 is stating: "The AS usually provides > a method for the RO to revoke the privileges at any point in time". > Revoking "the privileges" is different from revoking an "access token". > The second sentence of this Note 1 which is supposed to be about access > token is confusing. > The privileges may be changed at any point in time using a management > function. Access tokens can be short-lived and thus don't need to be > revoked. > Any call-back from a RS to an AS should be avoided in order to respect the > user's privacy. > > Therefore, I propose to remove the second part of this Note 1 and to > replace "the" by "a" at the beginning of the first sentence. > Note 2 is stating: > Note 2: an access token may act as a capability (i.e. bearer token) > or require an additional authentication by binding to a key (i.e. bound > token) > From the discussion on the list, I believe that we don't consider bearer > tokens. Note 2 should be removed. > So my proposal is as follows: > * Access token * > digitally signed data that contains specific rights and/or attributes > > Note: an access token can be issued to an end-user (usually requiring > his authentication) and subsequently refreshed. > > * 7) Definition of Grant* > The current definition is: > * Grant * > Definition: (verb): to permit, as a privilege given to an end-user to exercise > some rights and/or assert attributes during a specific duration > Definition: (noun): the act of granting > > The words ", as a privilege given to" are unnecessary" > I propose: > Grant > (verb): to permit an end-user to exercise some rights and/or *to* > assert *some *attributes *at a specific time and *during a specific > duration > (noun): the act of granting > > > *8) Definition of Resource* > The current definition is: > * Resource * > Definition: protected API served by a RS and accessed by a client, > if and only if a valid access token is provided > This definition is incorrect. This definition would be fine for a > Protected Resource. Change it into "Protected Resource": > * Protected Resource * > protected API served by a RS and *that can be *accessed by a client, > if and only if a valid access token is provided > If a definition of a Resource is needed, I propose: > * Resource * > public or protected resource from a RS > > * 9) Definition of Subject Information * > The current definition is: > > *Subject Information* > Definition: claim asserted locally by an AS about a person, organization > or device > Source: > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 > (unless we plan to use something specific to GNAP) > > This is information returned by an AS about an end-user. > I would thus simply propose instead: > > * Subject Information * > information returned to a Client by an AS about an end-user > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007096e305b6c0122f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Also for what it=E2=80=99s worth, the OpenID Connect =E2= =80=9Cclaims=E2=80=9D language would cover everything in that square. It=E2= =80=99s primarily about the end user, but doesn=E2=80=99t have to be as the= OIDC spec itself stats that it provides methods for "Claims about the= End-User and the Authentication event=E2=80=9D. In other words, a =E2=80=9Cclaim=E2= =80=9D is any statement made by an potentially authoritative source, the AS= .

    =C2=A0=E2=80=94 Justin
    =
    On Dec 18, 2020, at 12:02 PM, Fabien Imb= ault <fabien.imbault@gmail.com> wrote:

    Thanks Denis, that's a really useful feedback. I'll rev= iew that in more detail, but something that's really not clear to me is= the last one, subject information.

    1) is it about the e= nd-user ? or the RO ? (as is the current definition in V02)
    2) wh= y do we even need to call it subject information ? For instance if it's= about the end-user, it should only be end-user information.=C2=A0
    3) do we want to use entity or subject in the definitions ? (cf RO for in= stance). Regarding natural person vs entity we had a discussion on the mail= ing list previously.=C2=A0

    Cheers,
    Fabie= n

    On Fri, Dec 18, 2020 at 5:47 PM Denis <denis.ietf@free.fr>= wrote:
    =20 =20 =20

    FYI, the wiki page is there:=C2=A0 https://github.com/ietf-w= g-gnap/gnap-core-protocol/wiki/Terminology=

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ide= as and you will notice that a given term may be used in different ISO standards with a different definition. =C2= =A0

    I have nine comments (each one being numbered).

    1) Current definition of AS    : =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Authorization Server (AS) =
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: server that grants privileges to a particular end-user and= that provides them to a client in the form of an access token
    <= /span>

    This is fine in general (but see later another comment about it), but the word privileges is left undefined. =C2=A0

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page= : "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synon= ym of a permission.     =C2=A0

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

    =C2=A0=C2=A0=C2=A0=C2=A0 privilege =C2=A0
    = =C2=A0=C2=A0=C2=A0 access right
    = =C2=A0=C2=A0=C2=A0 permission
    = =C2=A0=C2=A0=C2=A0 authorization to a subject (3.15) to access a resource (3.14)
    <= /span><= br> =C2=A0=C2=A0=C2=A0 Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs w= hen the access request is granted according to its access control policy.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 T= he access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

    =C2=A0=C2=A0=C2=A0     Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 privilege: right = or attribute associated with an end-user

    with:
    =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 right: ability given t= o an end-user to perform a given operation on an object under the control of a RS

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Client
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: application that consumes reso= urces from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

    =C2=A0=C2=A0=C2=A0=C2=A0 Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
    =C2=A0=C2=A0=C2=A0     Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Client: applic= ation used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

    =C2=A0
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "acc= ess privileges".
    The words "a negotiation of<= /span>" should be deleted.

    This raises the point where this definition of a "Client" is using the wo= rding     "access privileges" whereas the definition of an "Authorization Server (AS)" =
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could = also live with "privileges". =C2=A0

    Hence my proposals:

    =C2=A0=C2=A0=C2=A0=C2=A0 Client
    =C2=A0=C2=A0=C2=A0=C2=A0 application operated     by an end-user     that consumes resources from one or s= everal RSs, possibly requiring access privileges from one or several ASs

    =C2=A0=C2=A0=C2=A0 Authorization Server (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 server that grants access privilege= s to a particular end-user and that provides them to a client in the form of an access token
    =C2=A0
    4) Definition of a Resource Server (RS)

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)

    =C2=A0=C2=A0=C2=A0=C2=A0 = Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server that provides operations on r= esources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the=C2=A0 above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
    =C2=A0
    5) Definition of Resource Owner =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0<= b> Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: personal or organizational ent= ity that may grant privileges on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural pe= rson" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsible party for the Resource(s= )
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 1 to entry: The Resource Owner = is responsible for granting, denying, and revoking Access to Resource(s).
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 2 to entry: The responsible Res= ource Owner is determined by the concrete Resource.

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 natural person or organizational en= tity that may grant or deny operations on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).


    6) Definition of Access Token     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: digitally signed data that con= tains specific rights and/or attributes
    =C2=A0=C2=A0=C2=A0     Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The AS usually p= rovides a method for the RO to revoke the privileges at any point in time.     = =C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from = the Note 1 is stating: "The AS usual= ly provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an &= quot;access token". The second sentence of this Note 1 which is supposed t= o be about access token is confusing.
    The privileges may be changed at = any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sent= ence.
    Note 2 is stating:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as foll= ows:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 digitally signed data that contains specif= ic rights and/or attributes =C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0     Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: (verb): to permit, as a privil= ege given to an end-user to exercise some rights and/or assert attributes during a specific duration
    =C2=A0=C2=A0=C2=A0     Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 (verb): to permit an end-user to exercise some rights and/or to assert so= me attributes at a specific time and during a specific duration
    =C2=A0=C2=A0=C2=A0 (noun): the act of granting
    =C2=A0
    =C2=A0
    8) Definition of Resource =C2=A0

    The current definition is= :

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definition: protected API served by = a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

    =C2=A0=C2=A0=C2=A0=C2= =A0 Protected Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 protected API served by a RS and that c= an be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 public or protected resource fr= om a RS


    9) Definition of Subject Information

    The current definition is:
    =C2=A0
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: h= ttps://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propo= se instead:

    =C2=A0=C2=A0=C2=A0=C2=A0 Subject Information
    =C2=A0=C2=A0=C2=A0=C2=A0 information returned to a Client by an AS = about an end-user
    =C2=A0
    Denis


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

    =
    Thanks Denis, that's a really useful feedback. I'l= l review that in more detail, but something that's really not clear to = me is the last one, subject information.

    1) is it about = the end-user ? or the RO ? (as is the current definition in V02)
    = 2) why do we even need to call it subject information ? For instance if it&= #39;s about the end-user, it should only be end-user information.=C2=A0
    3) do we want to use entity or subject in the definitions ? (cf RO f= or instance). Regarding natural person vs entity we had a discussion on the= mailing list previously.=C2=A0

    Cheers,
    = Fabien

    On Fri, Dec 18, 2020 at 5:47 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20

    = FYI, the wiki page is there:=C2=A0 https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ide= as and you will notice that a given term may be used in different ISO standards with a different definition. =C2= =A0

    I have nine comments (each one being numbered).

    1) Current definition of AS    : =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Authorization Server (AS) =
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: server that grants privileges to a particular end-user and= that provides them to a client in the form of an access token
    <= /span>

    This is fine in general (but see later another comment about it), but the word privileges is left undefined. =C2=A0

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page= : "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synon= ym of a permission.     =C2=A0

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

    =C2=A0=C2=A0=C2=A0=C2=A0 privilege =C2=A0
    = =C2=A0=C2=A0=C2=A0 access right
    = =C2=A0=C2=A0=C2=A0 permission
    = =C2=A0=C2=A0=C2=A0 authorization to a subject (3.15) to access a resource (3.14)
    <= /span><= br> =C2=A0=C2=A0=C2=A0 Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs w= hen the access request is granted according to its access control policy.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 T= he access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

    =C2=A0=C2=A0=C2=A0     Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 privilege: right = or attribute associated with an end-user

    with:
    =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 right: ability given t= o an end-user to perform a given operation on an object under the control of a RS

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Client
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: application that consumes reso= urces from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

    =C2=A0=C2=A0=C2=A0=C2=A0 Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
    =C2=A0=C2=A0=C2=A0     Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Client: applic= ation used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

    =C2=A0
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "acc= ess privileges".
    The words "a negotiation of<= /span>" should be deleted.

    This raises the point where this definition of a "Client" is using the wo= rding     "access privileges" whereas the definition of an "Authorization Server (AS)" =
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could = also live with "privileges". =C2=A0

    Hence my proposals:

    =C2=A0=C2=A0=C2=A0=C2=A0 Client
    =C2=A0=C2=A0=C2=A0=C2=A0 application operated     by an end-user     that consumes resources from one or s= everal RSs, possibly requiring access privileges from one or several ASs

    =C2=A0=C2=A0=C2=A0 Authorization Server (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 server that grants access privilege= s to a particular end-user and that provides them to a client in the form of an access token
    =C2=A0
    4) Definition of a Resource Server (RS)

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)

    =C2=A0=C2=A0=C2=A0=C2=A0 = Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server that provides operations on r= esources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the=C2=A0 above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
    =C2=A0
    5) Definition of Resource Owner =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0<= b> Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: personal or organizational ent= ity that may grant privileges on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural pe= rson" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsible party for the Resource(s= )
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 1 to entry: The Resource Owner = is responsible for granting, denying, and revoking Access to Resource(s).
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 2 to entry: The responsible Res= ource Owner is determined by the concrete Resource.

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 natural person or organizational en= tity that may grant or deny operations on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).


    6) Definition of Access Token     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: digitally signed data that con= tains specific rights and/or attributes
    =C2=A0=C2=A0=C2=A0     Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The AS usually p= rovides a method for the RO to revoke the privileges at any point in time.     = =C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from = the Note 1 is stating: "The AS usual= ly provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an &= quot;access token". The second sentence of this Note 1 which is supposed t= o be about access token is confusing.
    The privileges may be changed at = any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sent= ence.
    Note 2 is stating:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as foll= ows:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 digitally signed data that contains specif= ic rights and/or attributes =C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0     Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: (verb): to permit, as a privil= ege given to an end-user to exercise some rights and/or assert attributes during a specific duration
    =C2=A0=C2=A0=C2=A0     Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 (verb): to permit an end-user to exercise some rights and/or to assert so= me attributes at a specific time and during a specific duration
    =C2=A0=C2=A0=C2=A0 (noun): the act of granting
    =C2=A0
    =C2=A0
    8) Definition of Resource =C2=A0

    The current definition is= :

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definition: protected API served by = a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

    =C2=A0=C2=A0=C2=A0=C2= =A0 Protected Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 protected API served by a RS and that c= an be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 public or protected resource fr= om a RS


    9) Definition of Subject Information

    The current definition is:
    =C2=A0
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.o= rg/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propo= se instead:

    =C2=A0=C2=A0=C2=A0=C2=A0 Subject Information
    =C2=A0=C2=A0=C2=A0=C2=A0 information returned to a Client by an AS = about an end-user
    =C2=A0
    Denis

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000007096e305b6c0122f-- From nobody Fri Dec 18 09:06:21 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9F3A0AD0 for ; Fri, 18 Dec 2020 09:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQRUiXrHMtqo for ; Fri, 18 Dec 2020 09:06:17 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973923A0AD4 for ; Fri, 18 Dec 2020 09:06:16 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d78 with ME id 5t6C240045Eqqlm03t6CcN; Fri, 18 Dec 2020 18:06:13 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 18 Dec 2020 18:06:13 +0100 X-ME-IP: 90.79.54.243 To: Fabien Imbault Cc: txauth gnap References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> From: Denis Message-ID: <4ada0c13-719f-55ad-440d-a0adf4df789a@free.fr> Date: Fri, 18 Dec 2020 18:06:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E8BB9FD78CF8F1746BB8D38" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 18 Dec 2020 17:06:20 -0000 This is a multi-part message in MIME format. --------------1E8BB9FD78CF8F1746BB8D38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fabien, My mistake.  :-( The last definition (9) should be about "end-user information". *end-user information*: information returned to a Client by an AS about an end-user Denis > Thanks Denis, that's a really useful feedback. I'll review that in > more detail, but something that's really not clear to me is the last > one, subject information. > > 1) is it about the end-user ? or the RO ? (as is the current > definition in V02) > 2) why do we even need to call it subject information ? For instance > if it's about the end-user, it should only be end-user information. > 3) do we want to use entity or subject in the definitions ? (cf RO for > instance). Regarding natural person vs entity we had a discussion on > the mailing list previously. > > Cheers, > Fabien > > On Fri, Dec 18, 2020 at 5:47 PM Denis > wrote: > > FYI, the wiki page is > there:https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology > > > > FYI first, there is a useful web page where you can find all > the ISO definitions as well as the text for any ISO standard > (up to its definition section only): > https://www.iso.org/obp > > > This may provide some ideas and you will notice that a given > term may be used in different ISO standards with a different > definition. > > I have nine comments (each one being numbered). > _ > 1) Current definition of AS_: > > The current definition is: > > *Authorization Server (AS) * >      Definition: server that grants privileges to a > particular end-user and that provides them to a client in > the form of an access token > > > This is fine in general (but see later another comment about > it), but the word privileges is left undefined. > _ > 2) Definition of a privilege__ > _ > > > A suggested "privilege" definition has been proposed in the > wiki page: "A privilege is the right to perform an operation > (or action) on a Resource." See also other def > > . > In the "other def.", the term is considered to be a synonym > of a permission. > > ISO/IEC 29146:2016(en), 3.8 (very long) definition is the > following : > >      privilege > access right > permission > authorization to a subject (3.15) > to access a resource > (3.14) > > Note 1 to entry: Privilege is a necessary but not sufficient > condition for access. Access occurs when the access request > is granted according to its access control policy. >                               The access control policy is > based on privileges and may include other environmental > factors (e.g. time-of-day, location, etc.) > > Note 2 to entry: Privileges take the form of data presented > by a subject or obtained for a subject that is used by a > Policy Decision Point in order to grant or deny an operation >                               that a subject is willing to > perform on a resource. > (...) > > > I propose the following: > > *privilege*: right or attribute associated with an end-user > > > with: > *right*: ability given to an end-user to perform a given > operation on an object under the control of a RS > > *attribute*: characteristics or property related to an end-user > > __ > > > _3) Definition of a Client > > _ > > > The current definition is: > > > *Client * >      Definition: application that consumes resources from > one or several RSs, possibly requiring a negotiation of > access privileges with one or several ASs > >      Note: this specification differentiates between a > specific instance (the client instance, identified by its > public key) and the software running the instance >               (the client software). For some kinds of > client software, there could be many instances of a single > piece of client software. > Example: a client can be a mobile application, a web > application, etc. > > Previously, I proposed: > > *Client*: application used by an end-user to interact with > an AS or a RS > > The current definition is missing to indicate who is > operating the client. It is an end-user, i.e. it is not > another application, nor a process, nor an entity. > The definition should capture this point. > > > > A second point: the current definition is using the wording > "requiring a negotiation". There is no "negotiation". Either > the AS has or has not the "access privileges". > The words "a negotiation of" should be deleted. > > This raises the point where this definition of a "Client" is > using the wording "/access privileges/" whereas the > definition of an "Authorization Server (AS)" > is using the word "/privileges/". We should make both > definitions consistent. I have a slight preference for > "access privileges", but I could also live with "privileges". > > Hence my proposals: > > *     Client * >      application /operated/ /by an end-user /that consumes > resources from one or several RSs, possibly requiring > /access privileges from/ one or several ASs > * > **    Authorization Server (AS) * >      server that grants /access/ privileges to a particular > end-user and that provides them to a client in the form of > an access token > > _4) Definition of a Resource Server (RS) > _ > The current definition is: > * > **     Resource Server (RS) * > > >      Definition: server that provides operations on > /protected /resources; such operations require that the > client provides valid access tokens issued by an AS > > > A RS may offer both public resources and protected > resources. Valid access tokens are only needed for protected > resources. > I propose the following definition while merging the two > sentences: > > > > *Resource Server (RS) * >       server that provides operations on resources /where/ > protected operations require that the client provides /one > or more/ valid access tokens issued by /one or more ASs/ > > > In theabove modification I added "/one or more /". I am > presuming that GNAP will allow the presentation of more that > one access token from different ASs > in order to allow an end-user to perform one operation on a > protected resource. > > _5) Definition of Resource Owner_ _ > _ > The current definition is: > > > *Resource Owner (RO) * >      Definition: personal or organizational entity that may > grant privileges on resources it has authority upon > Note: the act of granting privileges may be manual (i.e. > through an interaction) or automatic (i.e. through > predefined rules). > > I don't know what a "personal entity" is but I know what a > "natural person" is. > > Furthermore, a Resource Owner is not granting privileges (or > access privileges) in the same way an AS is doing. > > It is interesting to take a look at ISO 20078-1:2019(en), > 3.1.4 where Resource Owner (RO) is defined as: > >       responsible party for the Resource(s) >       Note 1 to entry: The Resource Owner is responsible for > granting, denying, and revoking Access to Resource(s). >       Note 2 to entry: The responsible Resource Owner is > determined by the concrete Resource. > > > I propose: > > > *Resource Owner (RO) * > /natural person /or organizational 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) or automatic (i.e. > through predefined rules). > __ > > > _ > 6) Definition of Access Token__ > _ > > > The current definition is: > > >      Access token >      Definition: digitally signed data that contains > specific rights and/or attributes > Note 1: the access token can be issued to an end-user > (usually requiring his authentication) and subsequently > refreshed. > The AS usually provides a method for the RO to revoke the > privileges at any point in time. >     Note 2: an access token may act as a capability (i.e. > bearer token) or require an additional authentication by > binding to a key (i.e. bound token) > > > The definition is fine, but not the two Notes. > > > The second sentence from the Note 1 is stating: "The AS > usually provides a method for the RO to revoke the > privileges at any point in time". > Revoking "the privileges" is different from revoking an > "access token". The second sentence of this Note 1 which is > supposed to be about access token is confusing. > The privileges may be changed at any point in time using a > management function. Access tokens can be short-lived and > thus don't need to be revoked. > Any call-back from a RS to an AS should be avoided in order > to respect the user's privacy. > > Therefore, I propose to remove the second part of this Note > 1 and to replace "the" by "a" at the beginning of the first > sentence. > Note 2 is stating: > Note 2: an access token may act as a capability (i.e. bearer > token) or require an additional authentication by binding to > a key (i.e. bound token) > > > From the discussion on the list, I believe that we don't > consider bearer tokens. Note 2 should be removed. > > > So my proposal is as follows: > > > *     Access token * >      digitally signed data that contains specific rights > and/or attributes > Note: an access token can be issued to an end-user (usually > requiring his authentication) and subsequently refreshed. > __ > > > _ > 7) Definition of Grant__ > _ > > > The current definition is: > > > *     Grant * >      Definition: (verb): to permit, as a privilege given to > an end-user to exercise some rights and/or assert attributes > during a specific duration > Definition: (noun): the act of granting > > The words ", as a privilege given to" are unnecessary" > > > I propose: > > >      Grant >      (verb): to permit an end-user to exercise some rights > and/or /to/ assert /some /attributes /at a specific time and > /during a specific duration > (noun): the act of granting > > > _8) Definition of Resource_ _ > _ > > > The current definition is: > > > *     Resource * >       Definition: protected API served by a RS and accessed > by a client, if and only if a valid access token is provided > > > This definition is incorrect. This definition would be fine > for a Protected Resource. Change it into "Protected Resource": > > > *     Protected Resource * >      protected API served by a RS and /that can be /accessed > by a client, if and only if a valid access token is provided > > > If a definition of a Resource is needed, I propose: > > > *     Resource ** > ***public or protected resource from a RS > > > _ > 9) Definition of Subject Information > _ > The current definition is: > > *Subject Information* > Definition: claim asserted locally by an AS about a person, > organization or device > Source: > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 > > (unless we plan to use something specific to GNAP) > > This is information returned by an AS about an end-user. > > > I would thus simply propose instead: > * > **     Subject Information * >      information returned to a Client by an AS about an > end-user > > Denis > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --------------1E8BB9FD78CF8F1746BB8D38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi Fabien,

    My mistake.  :-(

    The last definition (9) should be about "end-user information".

          end-user information: information returned to a Client by an AS about an end-user

    Denis


    Thanks Denis, that's a really useful feedback. I'll review that in more detail, but something that's really not clear to me is the last one, subject information.

    1) is it about the end-user ? or the RO ? (as is the current definition in V02)
    2) why do we even need to call it subject information ? For instance if it's about the end-user, it should only be end-user information. 
    3) do we want to use entity or subject in the definitions ? (cf RO for instance). Regarding natural person vs entity we had a discussion on the mailing list previously. 

    Cheers,
    Fabien

    On Fri, Dec 18, 2020 at 5:47 PM Denis <denis.ietf@free.fr> wrote:

    FYI, the wiki page is there:  https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ideas and you will notice that a given term may be used in different ISO standards with a different definition.  

    I have nine comments (each one being numbered).

    1) Current definition of AS    :  

    The current definition is:

         Authorization Server (AS)
         Definition: server that grants privileges to a particular end-user and that provides them to a client in the form of an access token

    This is fine in general (but see later another comment about it), but the word privileges is left undefined.  

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page: "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synonym of a permission.      

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

         privilege  
        access right
        permission
        authorization to a subject (3.15) to access a resource (3.14)

            Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request is granted according to its access control policy.
                                  The access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

            Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
                                  that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

            privilege: right or attribute associated with an end-user

    with:
            right: ability given to an end-user to perform a given operation on an object under the control of a RS

              attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

         Client
         Definition: application that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

         Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
                  (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
            Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
     
              Client: application used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

     
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "access privileges".
    The words "a negotiation of" should be deleted.

    This raises the point where this definition of a "Client" is using the wording     "access privileges" whereas the definition of an "Authorization Server (AS)"
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could also live with "privileges".  

    Hence my proposals:

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

        Authorization Server (AS)
         server that grants access privileges to a particular end-user and that provides them to a client in the form of an access token
     
    4) Definition of a Resource Server (RS)

    The current definition is:

         Resource Server (RS)

         Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


          Resource Server (RS)
          server that provides operations on resources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the  above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
     
    5) Definition of Resource Owner  

    The current definition is:

         Resource Owner (RO)
         Definition: personal or organizational entity that may grant privileges on resources it has authority upon
            Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural person" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

          responsible party for the Resource(s)
          Note 1 to entry: The Resource Owner is responsible for granting, denying, and revoking Access to Resource(s).
          Note 2 to entry: The responsible Resource Owner is determined by the concrete Resource.

    I propose:

         Resource Owner (RO)
         natural person or organizational 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) or automatic (i.e. through predefined rules).


    6) Definition of Access Token      

    The current definition is:

         Access token
         Definition: digitally signed data that contains specific rights and/or attributes
            Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
                    The AS usually provides a method for the RO to revoke the privileges at any point in time.         
        Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from the Note 1 is stating: "The AS usually provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an "access token". The second sentence of this Note 1 which is supposed to be about access token is confusing.
    The privileges may be changed at any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sentence.
    Note 2 is stating:
              Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as follows:

         Access token
         digitally signed data that contains specific rights and/or attributes   
            Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant      

    The current definition is:

         Grant
         Definition: (verb): to permit, as a privilege given to an end-user to exercise some rights and/or assert attributes during a specific duration
            Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

         Grant
         (verb): to permit an end-user to exercise some rights and/or to assert some attributes at a specific time and during a specific duration
            (noun): the act of granting
     
     
    8) Definition of Resource  

    The current definition is:

         Resource
          Definition: protected API served by a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

         Protected Resource
         protected API served by a RS and that can be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

         Resource
         public or protected resource from a RS


    9) Definition of Subject Information

    The current definition is:
     
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propose instead:

         Subject Information
         information returned to a Client by an AS about an end-user
     
    Denis

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


    --------------1E8BB9FD78CF8F1746BB8D38-- From nobody Fri Dec 18 09:42:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B56F3A0B21 for ; Fri, 18 Dec 2020 09:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p06ccr99LA2b for ; Fri, 18 Dec 2020 09:42:37 -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 938503A0B17 for ; Fri, 18 Dec 2020 09:42:36 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BIHgUMB005995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Dec 2020 12:42:30 -0500 From: Justin Richer Message-Id: <0E0E3DD6-24E0-47BE-8441-9426C1FB7AEE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1637BB2E-05F5-4A6D-83EA-6CCB48271AA1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 18 Dec 2020 12:42:30 -0500 In-Reply-To: Cc: Denis , txauth gnap To: Fabien Imbault References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 18 Dec 2020 17:42:41 -0000 --Apple-Mail=_1637BB2E-05F5-4A6D-83EA-6CCB48271AA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There=E2=80=99s a subtlety about =E2=80=9Csubject information=E2=80=9D = that I think we need to be careful not to lose, in that it=E2=80=99s the = intersection of two different aspects of data rights being given to the = client. I=E2=80=99m not sure how best to frame this, so apologies if = this sprawls a bit: First, there=E2=80=99s the dimension of how the data is transmitted to = the client. This is a fundamental difference between rights associated = with an access token and data being sent back directly to the client in = a response message from the AS. The access token is handled by the = =E2=80=9Cresources=E2=80=9D request (pending proposed = restructure/rename, but that=E2=80=99s the current spec). This tells the = AS the things the token can do, but as we all know a big part of that in = practice is about what data the token can be used for, and therefore = what data the client has access to. The other information is what=E2=80=99= s sent directly to the client, and it=E2=80=99s somewhat =E2=80=9Cnew=E2=80= =9D for GNAP. OpenID Connect showed us the value of passing back an = assertion directly to the client, and GNAP is making this kind of = =E2=80=9CDirect returned information=E2=80=9D a first-class citizen, to = the point that mechanisms for returning this is in our charter. This = could be wrapped in an assertion or returned as raw data, and GNAP = currently allows both. The second dimension is what the data is about, regardless of how it = gets back. There are lots of ways to look at this, but one fundamental = question is whether the data is :about: the end user or not. Identity is = far from the only use case for GNAP, but we know that it=E2=80=99s going = to be a driving one for many developers. And when you=E2=80=99re talking = about identity information, the distinction between the RQ and RO really = comes into sharp relief: are you asking about the current user, or about = some other user on a different system, and are they the same person? So in total it=E2=80=99s something like this: | Delivery Method | | | | Direct | Resource | -----------------------------------------------+ End User | Subject | UserInfo | Data | Information | Endpoint | Subject -------------------------------------+ Other | ??? | Resource | | | Server API | -----------------------------------------------+ Is this a useful diagram and distinction to make in our discussion? Also for what it=E2=80=99s worth, the OpenID Connect =E2=80=9Cclaims=E2=80= =9D language would cover everything in that square. It=E2=80=99s = primarily about the end user, but doesn=E2=80=99t have to be as the OIDC = spec itself stats that it provides methods for "Claims about the = End-User and the Authentication event=E2=80=9D. In other words, a = =E2=80=9Cclaim=E2=80=9D is any statement made by an potentially = authoritative source, the AS. =E2=80=94 Justin > On Dec 18, 2020, at 12:02 PM, Fabien Imbault = wrote: >=20 > Thanks Denis, that's a really useful feedback. I'll review that in = more detail, but something that's really not clear to me is the last = one, subject information. >=20 > 1) is it about the end-user ? or the RO ? (as is the current = definition in V02) > 2) why do we even need to call it subject information ? For instance = if it's about the end-user, it should only be end-user information.=20 > 3) do we want to use entity or subject in the definitions ? (cf RO for = instance). Regarding natural person vs entity we had a discussion on the = mailing list previously.=20 >=20 > Cheers, > Fabien >=20 > On Fri, Dec 18, 2020 at 5:47 PM Denis > wrote: >=20 > FYI, the wiki page is there: = https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology = > FYI first, there is a useful web page where you can find all the ISO = definitions as well as the text for any ISO standard (up to its = definition section only):=20 > https://www.iso.org/obp =20 > This may provide some ideas and you will notice that a given term may = be used in different ISO standards with a different definition. =20 >=20 > I have nine comments (each one being numbered).=20 >=20 > 1) Current definition of AS: =20 >=20 > The current definition is:=20 >=20 > Authorization Server (AS)=20 > Definition: server that grants privileges to a particular = end-user and that provides them to a client in the form of an access = token=20 > This is fine in general (but see later another comment about it), but = the word privileges is left undefined. =20 >=20 > 2) Definition of a privilege=20 > A suggested "privilege" definition has been proposed in the wiki page: = "A privilege is the right to perform an operation (or action) on a = Resource." See also other def = .=20 > In the "other def.", the term is considered to be a synonym of a = permission. =20 >=20 > ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :=20= >=20 > privilege =20 > access right=20 > permission=20 > authorization to a subject (3.15) = to access a resource (3.14) = =20 >=20 > Note 1 to entry: Privilege is a necessary but not sufficient = condition for access. Access occurs when the access request is granted = according to its access control policy.=20 > The access control policy is based on = privileges and may include other environmental factors (e.g. = time-of-day, location, etc.)=20 >=20 > Note 2 to entry: Privileges take the form of data presented by a = subject or obtained for a subject that is used by a Policy Decision = Point in order to grant or deny an operation=20 > that a subject is willing to perform on = a resource.=20 > (...)=20 > I propose the following:=20 >=20 > privilege: right or attribute associated with an end-user=20 > with:=20 > right: ability given to an end-user to perform a given = operation on an object under the control of a RS=20 >=20 > attribute: characteristics or property related to an end-user=20 >=20 > 3) Definition of a Client=20 >=20 > The current definition is:=20 > Client=20 > Definition: application that consumes resources from one or = several RSs, possibly requiring a negotiation of access privileges with = one or several ASs=20 >=20 > Note: this specification differentiates between a specific = instance (the client instance, identified by its public key) and the = software running the instance=20 > (the client software). For some kinds of client = software, there could be many instances of a single piece of client = software.=20 > Example: a client can be a mobile application, a web application, = etc.=20 >=20 > Previously, I proposed: > =20 > Client: application used by an end-user to interact with an AS = or a RS=20 >=20 > The current definition is missing to indicate who is operating the = client. It is an end-user, i.e. it is not another application, nor a = process, nor an entity.=20 > The definition should capture this point. > =20 > A second point: the current definition is using the wording "requiring = a negotiation". There is no "negotiation". Either the AS has or has not = the "access privileges".=20 > The words "a negotiation of" should be deleted.=20 >=20 > This raises the point where this definition of a "Client" is using the = wording "access privileges" whereas the definition of an "Authorization = Server (AS)"=20 > is using the word "privileges". We should make both definitions = consistent. I have a slight preference for "access privileges", but I = could also live with "privileges". =20 >=20 > Hence my proposals:=20 >=20 > Client=20 > application operated by an end-user that consumes resources from = one or several RSs, possibly requiring access privileges from one or = several ASs=20 >=20 > Authorization Server (AS)=20 > server that grants access privileges to a particular end-user and = that provides them to a client in the form of an access token=20 > =20 > 4) Definition of a Resource Server (RS)=20 >=20 > The current definition is:=20 >=20 > Resource Server (RS)=20 > Definition: server that provides operations on protected = resources; such operations require that the client provides valid access = tokens issued by an AS=20 > A RS may offer both public resources and protected resources. Valid = access tokens are only needed for protected resources.=20 > I propose the following definition while merging the two sentences:=20 >=20 > Resource Server (RS)=20 > server that provides operations on resources where protected = operations require that the client provides one or more valid access = tokens issued by one or more ASs=20 > In the above modification I added "one or more ". I am presuming that = GNAP will allow the presentation of more that one access token from = different ASs=20 > in order to allow an end-user to perform one operation on a protected = resource.=20 > =20 > 5) Definition of Resource Owner =20 >=20 > The current definition is:=20 > Resource Owner (RO)=20 > Definition: personal or organizational entity that may grant = privileges on resources it has authority upon=20 > Note: the act of granting privileges may be manual (i.e. through = an interaction) or automatic (i.e. through predefined rules).=20 >=20 > I don't know what a "personal entity" is but I know what a "natural = person" is.=20 >=20 > Furthermore, a Resource Owner is not granting privileges (or access = privileges) in the same way an AS is doing.=20 >=20 > It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where = Resource Owner (RO) is defined as:=20 >=20 > responsible party for the Resource(s)=20 > Note 1 to entry: The Resource Owner is responsible for granting, = denying, and revoking Access to Resource(s).=20 > Note 2 to entry: The responsible Resource Owner is determined by = the concrete Resource.=20 > I propose:=20 > Resource Owner (RO)=20 > natural person or organizational entity that may grant or deny = operations on resources it has authority upon=20 > Note: the act of granting or denying an operation may be manual = (i.e. through an interaction) or automatic (i.e. through predefined = rules).=20 >=20 > 6) Definition of Access Token =20 > The current definition is:=20 > Access token=20 > Definition: digitally signed data that contains specific rights = and/or attributes=20 > Note 1: the access token can be issued to an end-user (usually = requiring his authentication) and subsequently refreshed. > The AS usually provides a method for the RO to revoke = the privileges at any point in time. =20 > Note 2: an access token may act as a capability (i.e. bearer = token) or require an additional authentication by binding to a key (i.e. = bound token)=20 > The definition is fine, but not the two Notes.=20 > The second sentence from the Note 1 is stating: "The AS usually = provides a method for the RO to revoke the privileges at any point in = time".=20 > Revoking "the privileges" is different from revoking an "access = token". The second sentence of this Note 1 which is supposed to be about = access token is confusing.=20 > The privileges may be changed at any point in time using a management = function. Access tokens can be short-lived and thus don't need to be = revoked.=20 > Any call-back from a RS to an AS should be avoided in order to respect = the user's privacy.=20 >=20 > Therefore, I propose to remove the second part of this Note 1 and to = replace "the" by "a" at the beginning of the first sentence.=20 > Note 2 is stating:=20 > Note 2: an access token may act as a capability (i.e. bearer = token) or require an additional authentication by binding to a key (i.e. = bound token)=20 > =46rom the discussion on the list, I believe that we don't consider = bearer tokens. Note 2 should be removed.=20 > So my proposal is as follows:=20 > Access token=20 > digitally signed data that contains specific rights and/or = attributes =20 > Note: an access token can be issued to an end-user (usually = requiring his authentication) and subsequently refreshed.=20 >=20 > 7) Definition of Grant =20 > The current definition is:=20 > Grant=20 > Definition: (verb): to permit, as a privilege given to an = end-user to exercise some rights and/or assert attributes during a = specific duration=20 > Definition: (noun): the act of granting=20 >=20 > The words ", as a privilege given to" are unnecessary"=20 > I propose:=20 > Grant > (verb): to permit an end-user to exercise some rights and/or to = assert some attributes at a specific time and during a specific duration=20= > (noun): the act of granting=20 > =20 > =20 > 8) Definition of Resource =20 > The current definition is:=20 > Resource=20 > Definition: protected API served by a RS and accessed by a = client, if and only if a valid access token is provided=20 > This definition is incorrect. This definition would be fine for a = Protected Resource. Change it into "Protected Resource":=20 > Protected Resource=20 > protected API served by a RS and that can be accessed by a = client, if and only if a valid access token is provided=20 > If a definition of a Resource is needed, I propose:=20 > Resource=20 > public or protected resource from a RS >=20 > 9) Definition of Subject Information=20 >=20 > The current definition is:=20 > =20 > Subject Information=20 > Definition: claim asserted locally by an AS about a person, = organization or device=20 > Source: = https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 = = (unless we plan to use something specific to GNAP)=20 >=20 > This is information returned by an AS about an end-user.=20 > I would thus simply propose instead: >=20 > Subject Information=20 > information returned to a Client by an AS about an end-user=20 > =20 > Denis >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_1637BB2E-05F5-4A6D-83EA-6CCB48271AA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There=E2=80=99s a subtlety about =E2=80=9Csubject = information=E2=80=9D that I think we need to be careful not to lose, in = that it=E2=80=99s the intersection of two different aspects of data = rights being given to the client. I=E2=80=99m not sure how best to frame = this, so apologies if this sprawls a bit:

    First, there=E2=80=99s the dimension of = how the data is transmitted to the client. This is a fundamental = difference between rights associated with an access token and data being = sent back directly to the client in a response message from the AS. The = access token is handled by the =E2=80=9Cresources=E2=80=9D request = (pending proposed restructure/rename, but that=E2=80=99s the current = spec). This tells the AS the things the token can do, but as we all know = a big part of that in practice is about what data the token can be used = for, and therefore what data the client has access to. The other = information is what=E2=80=99s sent directly to the client, and it=E2=80=99= s somewhat =E2=80=9Cnew=E2=80=9D for GNAP. OpenID Connect showed us the = value of passing back an assertion directly to the client, and GNAP is = making this kind of =E2=80=9CDirect returned information=E2=80=9D a = first-class citizen, to the point that mechanisms for returning this is = in our charter. This could be wrapped in an assertion or returned as raw = data, and GNAP currently allows both.

    The second dimension is what the data = is about, regardless of how it gets back. There are lots of ways to look = at this, but one fundamental question is whether the data is :about: the = end user or not. Identity is far from the only use case for GNAP, but we = know that it=E2=80=99s going to be a driving one for many developers. = And when you=E2=80=99re talking about identity information, the = distinction between the RQ and RO really comes into sharp relief: are = you asking about the current user, or about some other user on a = different system, and are they the same person?

    So in total it=E2=80=99s something like = this:

          =              |     Delivery = Method       |
              =          |           =                 = |
     =                  | Direct =      |  Resource   |
    -----------------------------------------------+
          =     End User | Subject     |  UserInfo   = |
     =   Data           | Information | =  Endpoint   |
     Subject =  -------------------------------------+
          =       Other  | ???         | =  Resource   |
                    =    |             |  Server = API |
    -----------------------------------------------+

    Is this a = useful diagram and distinction to make in our discussion?

    Also for what it=E2=80=99s= worth, the OpenID Connect =E2=80=9Cclaims=E2=80=9D language would cover = everything in that square. It=E2=80=99s primarily about the end user, = but doesn=E2=80=99t have to be as the OIDC spec itself stats that it = provides methods for "Claims about the End-User and the Authentication event=E2=80=9D. In other words, a = =E2=80=9Cclaim=E2=80=9D is any statement made by an potentially = authoritative source, the AS.

     =E2=80=94 Justin

    On Dec 18, 2020, at 12:02 PM, = Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Thanks Denis, that's a really = useful feedback. I'll review that in more detail, but something that's = really not clear to me is the last one, subject information.

    1) is it about the = end-user ? or the RO ? (as is the current definition in V02)
    2) why do we even need to call it subject information ? For = instance if it's about the end-user, it should only be end-user = information. 
    3) do we want to use entity or = subject in the definitions ? (cf RO for instance). Regarding natural = person vs entity we had a discussion on the mailing list = previously. 

    Cheers,
    Fabien

    On Fri, Dec 18, 2020 at 5:47 PM Denis <denis.ietf@free.fr> = wrote:
    =20 =20 =20

    FYI, the wiki page is there:  https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Termino= logy

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only): =
    https://www.iso.org/obp

    This may provide some ideas and you will = notice that a given term may be used in different ISO standards with a different definition.  

    I have nine comments (each one being numbered).

    1) Current definition of AS    :  

    The current definition is:

         Authorization Server (AS)
         Definition: server = that grants privileges= to a particular end-user and that provides them to a client in the form of an access token

    This is fine in general (but see later another comment about it), but the word = privileges is left undefined.  

    2) Definition of a privilege     =

    A suggested "privilege" definition has been proposed in the wiki page: "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synonym of a permission.      

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :     =

         = privilege  
        access right
        permission
        authorization to a subject (3.15) to access a resource (3.14)

            Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request is granted according to its access control policy.
    =             &n= bsp;                 The = access control policy is = based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

            Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to = grant or deny an operation
    =             &n= bsp;           &nbs= p;     that a subject is willing to perform on a = resource    .     =
    (...) =

    I propose the following:

            privilege: right or attribute associated with an end-user

    with:
            right: = ability given to an end-user to perform a given operation on an object under the control of a RS     =

              attribute: characteristics or property related to an end-user =

    3) Definition of a Client

    The current definition is:

         Client
         Definition: application that consumes = resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

         Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =             &n= bsp; (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
            Example: a client can be a mobile application, a web application, etc. =

    Previously, I proposed:
     
              Client: application used by an end-user to interact with an AS or a RS
    =
    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

     
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "access privileges".
    The words "a = negotiation of" should be deleted.

    This raises the point where this definition of a "Client" is using the wording =     "access privileges" whereas the definition of an "Authorization Server (AS)"
    is using the word "privileges". We should make both = definitions consistent. I have a slight preference for "access privileges", but I could also live with "privileges".  

    Hence my proposals:

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

        Authorization Server (AS)
         server that grants access privileges to a particular end-user and that provides them to a client in the form of an access = token
     
    4) Definition of a Resource Server (RS)

    The current definition is:

         Resource Server (RS) =

         Definition: server = that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


          Resource Server = (RS)
          server that provides operations = on resources where protected operations require that the client provides one or more = valid access tokens issued by one or more ASs     =

    In the  above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
     
    5) Definition of Resource Owner  

    The current definition is:

         = Resource Owner (RO)
         Definition: personal or organizational = entity that may grant privileges on resources it has authority upon     =
            Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural person" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.
    =
    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

          responsible party for the = Resource(s)
          Note 1 to entry: The Resource = Owner is responsible for granting, denying, and revoking Access to Resource(s).
          Note 2 to entry: The responsible = Resource Owner is determined by the concrete Resource.

    I propose:

         Resource = Owner (RO)
         natural person or = organizational 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) or automatic (i.e. through predefined rules). =


    6) Definition of Access Token      

    The current definition is:

         Access token
         Definition: digitally signed data that = contains specific rights and/or attributes     =
            Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =             &n= bsp;   The AS = usually provides a method for the RO to revoke the privileges at any point in time.         
        Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from the Note 1 is = stating: "The AS usually = provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an "access token". The second sentence of this Note 1 which is supposed to be about access token is confusing.
    The privileges may be changed at any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sentence.
    Note 2 is stating:     =
              Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    =46rom the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as follows:

         Access = token
         digitally signed data that contains = specific rights and/or attributes   
            Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant      

    The current definition is:

         Grant =
         Definition: (verb): to permit, as a = privilege given to an end-user to exercise = some rights and/or assert attributes during a specific = duration
            Definition: (noun): the act of granting =

    The words ", as a privilege given to" are unnecessary"

    I propose:

         Grant
         (verb): to permit an end-user to exercise some rights and/or to assert some attributes at a specific time and during a specific = duration
            (noun): the act of granting =
     
     
    8) Definition of Resource  

    The current definition is:

         = Resource
          Definition: protected API served = by a RS and accessed by a client, if and only if a valid access token is provided     =

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

         = Protected Resource
         protected API served by a RS and that can be accessed by a client, if and only if a valid access token is provided     =

    If a definition of a Resource is needed, I propose:

         = Resource
         public or = protected resource from a RS


    9) Definition of Subject Information

    The current definition is:
     
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.org/html/draft-ietf-secevent-subject-identif= iers-06 (unless we plan to use something specific to GNAP) =

    This is information returned by an AS about an end-user.

    I would thus simply propose instead:

         Subject Information =
         information returned to a Client by an = AS about an end-user
     
    Denis


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

    = --Apple-Mail=_1637BB2E-05F5-4A6D-83EA-6CCB48271AA1-- From nobody Fri Dec 18 09:45:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5E53A0B18 for ; Fri, 18 Dec 2020 09:45:54 -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 ydWvOgKeevVY for ; Fri, 18 Dec 2020 09:45:51 -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 C1EDA3A0CD9 for ; Fri, 18 Dec 2020 09:45:50 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id w18so2822627iot.0 for ; Fri, 18 Dec 2020 09:45: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=7sK+ZpMUJyqwkaotre2yX2LvHQMlRu5UHwp77HcE4LI=; b=V674Egh8OcOLbeqOrbQa0COs3L8A0bFnVpJj/oRMiZoJmgQlt6LqqoiHAZm31wpQxU T2fICV+W7//n1pHH6SP2NlJL4tqrneN3VwiSFM82X2qWHufzRecxkhMm8tRZMFl79CaK tepWeS/B8O/8vMb0CYwmwhxue7vIemdfYR8IRBpTuVimfWIdb1Eq9AmWIfIp98wf7lhZ e/DCshtl44vjTHV3WaTQYf3TrY7fTL4ji2HUOPFan7zCSDBCGXNO+21kJFWIMTZOLaos W9HIIyrRTOu4h2tudfustfzNzB99pxGetvsRgCrhxKxIGPXZzMgnq7Xvm+drB6WEeR4L z31w== 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=7sK+ZpMUJyqwkaotre2yX2LvHQMlRu5UHwp77HcE4LI=; b=ceXysLKFZUulJluXenH+2zrYzS2m9/IXKZhcABLeStZDb76Az80u6b99u0ha9TTPKl QjD9onbp9Mw4tjveZ3I0wBAnSreQHats5WWcTJ8MsmVQn6VAqI+/LkAlQjtakrj/c/2z mDTPVxvpJRlKNcydqBHsyIlGeN8n5G5eqliS+fCHS00ng0N/Fud1SllRdIAVSV0C0gy0 ZwS0Q6h3v9o1cXAxhcJG9DGFdit8cZPDUoeA2wxdFYdZeTS3zlmmElJcoyOT6W6jWyeE GqPMbDSZGfeRzq+W1YYnGyUfw/oimJkkgQgnYGrJ/lm2+hGVMylwGwZ7F2xW6soj2cbB F0Rw== X-Gm-Message-State: AOAM533GVLPmI2s0bGgowYUv143m/WrmZaUUjidwkGYOL+AspVZkWABI Gwo7iYLN0hwYSeJR8pcRvj0g4m7xawalNuPgwsQ= X-Google-Smtp-Source: ABdhPJw0Y9/accVt6sh1P171+PwEYXgEdj8QOJbE32tCyiTYfG2ihW42GWUg0CGd0s+YMoYkl75aH29qX7vE+eSnUnY= X-Received: by 2002:a02:c98d:: with SMTP id b13mr4665146jap.124.1608313549845; Fri, 18 Dec 2020 09:45:49 -0800 (PST) MIME-Version: 1.0 References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> <0E0E3DD6-24E0-47BE-8441-9426C1FB7AEE@mit.edu> In-Reply-To: <0E0E3DD6-24E0-47BE-8441-9426C1FB7AEE@mit.edu> From: Fabien Imbault Date: Fri, 18 Dec 2020 18:45:37 +0100 Message-ID: To: Justin Richer Cc: Denis , txauth gnap Content-Type: multipart/alternative; boundary="000000000000d3790905b6c0add9" Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 18 Dec 2020 17:45:55 -0000 --000000000000d3790905b6c0add9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes that's useful. In that case we're closer to the definition that we have in my previous email, than to that proposed by Denis. Le ven. 18 d=C3=A9c. 2020 =C3=A0 18:42, Justin Richer a = =C3=A9crit : > There=E2=80=99s a subtlety about =E2=80=9Csubject information=E2=80=9D th= at I think we need to be > careful not to lose, in that it=E2=80=99s the intersection of two differe= nt aspects > of data rights being given to the client. I=E2=80=99m not sure how best t= o frame > this, so apologies if this sprawls a bit: > > First, there=E2=80=99s the dimension of how the data is transmitted to th= e client. > This is a fundamental difference between rights associated with an access > token and data being sent back directly to the client in a response messa= ge > from the AS. The access token is handled by the =E2=80=9Cresources=E2=80= =9D request > (pending proposed restructure/rename, but that=E2=80=99s the current spec= ). This > tells the AS the things the token can do, but as we all know a big part o= f > that in practice is about what data the token can be used for, and > therefore what data the client has access to. The other information is > what=E2=80=99s sent directly to the client, and it=E2=80=99s somewhat =E2= =80=9Cnew=E2=80=9D for GNAP. > OpenID Connect showed us the value of passing back an assertion directly = to > the client, and GNAP is making this kind of =E2=80=9CDirect returned info= rmation=E2=80=9D a > first-class citizen, to the point that mechanisms for returning this is i= n > our charter. This could be wrapped in an assertion or returned as raw dat= a, > and GNAP currently allows both. > > The second dimension is what the data is about, regardless of how it gets > back. There are lots of ways to look at this, but one fundamental questio= n > is whether the data is :about: the end user or not. Identity is far from > the only use case for GNAP, but we know that it=E2=80=99s going to be a d= riving one > for many developers. And when you=E2=80=99re talking about identity infor= mation, > the distinction between the RQ and RO really comes into sharp relief: are > you asking about the current user, or about some other user on a differen= t > system, and are they the same person? > > So in total it=E2=80=99s something like this: > > | Delivery Method | > | | > | Direct | Resource | > -----------------------------------------------+ > End User | Subject | UserInfo | > Data | Information | Endpoint | > Subject -------------------------------------+ > Other | ??? | Resource | > | | Server API | > -----------------------------------------------+ > > Is this a useful diagram and distinction to make in our discussion? > > Also for what it=E2=80=99s worth, the OpenID Connect =E2=80=9Cclaims=E2= =80=9D language would cover > everything in that square. It=E2=80=99s primarily about the end user, but= doesn=E2=80=99t > have to be as the OIDC spec itself stats that it provides methods for > "Claims about the End-User and the Authentication event=E2=80=9D. In othe= r words, a > =E2=80=9Cclaim=E2=80=9D is any statement made by an potentially authorita= tive source, the > AS. > > =E2=80=94 Justin > > On Dec 18, 2020, at 12:02 PM, Fabien Imbault > wrote: > > Thanks Denis, that's a really useful feedback. I'll review that in more > detail, but something that's really not clear to me is the last one, > subject information. > > 1) is it about the end-user ? or the RO ? (as is the current definition i= n > V02) > 2) why do we even need to call it subject information ? For instance if > it's about the end-user, it should only be end-user information. > 3) do we want to use entity or subject in the definitions ? (cf RO for > instance). Regarding natural person vs entity we had a discussion on the > mailing list previously. > > Cheers, > Fabien > > On Fri, Dec 18, 2020 at 5:47 PM Denis wrote: > >> >> FYI, the wiki page is there: >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> FYI first, there is a useful web page where you can find all the ISO >> definitions as well as the text for any ISO standard (up to its definiti= on >> section only): >> https://www.iso.org/obp >> This may provide some ideas and you will notice that a given term may be >> used in different ISO standards with a different definition. >> >> I have nine comments (each one being numbered). >> >> * 1) Current definition of AS*: >> >> The current definition is: >> >> *Authorization Server (AS) * >> Definition: server that grants privileges to a particular end-user >> and that provides them to a client in the form of an access token >> This is fine in general (but see later another comment about it), but th= e >> word privileges is left undefined. >> >> * 2) Definition of a privilege* >> A suggested "privilege" definition has been proposed in the wiki page: "= A >> privilege is the right to perform an operation (or action) on a Resource= ." >> See also other def >> >> . >> In the "other def.", the term is considered to be a synonym of a >> permission. >> >> ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following : >> >> privilege >> access right >> permission >> authorization to a subject (3.15) >> to access a resource (3.14) >> >> >> Note 1 to entry: Privilege is a necessary but not sufficient >> condition for access. Access occurs when the access request is granted >> according to its access control policy. >> The access control policy is based on >> privileges and may include other environmental factors (e.g. >> time-of-day, location, etc.) >> >> Note 2 to entry: Privileges take the form of data presented by a >> subject or obtained for a subject that is used by a Policy Decision Poin= t >> in order to grant or deny an operation >> that a subject is willing to perform on a >> resource. >> (...) >> I propose the following: >> >> *privilege*: right or attribute associated with an end-user >> with: >> *right*: ability given to an end-user to perform a given >> operation on an object under the control of a RS >> >> *attribute*: characteristics or property related to an end-user >> >> >> >> *3) Definition of a Client * The current definition is: >> *Client * >> Definition: application that consumes resources from one or several >> RSs, possibly requiring a negotiation of access privileges with one or >> several ASs >> >> Note: this specification differentiates between a specific instance >> (the client instance, identified by its public key) and the software >> running the instance >> (the client software). For some kinds of client software, >> there could be many instances of a single piece of client software. >> Example: a client can be a mobile application, a web application, >> etc. >> >> Previously, I proposed: >> >> *Client*: application used by an end-user to interact with an AS >> or a RS >> >> The current definition is missing to indicate who is operating the >> client. It is an end-user, i.e. it is not another application, nor a >> process, nor an entity. >> The definition should capture this point. >> A second point: the current definition is using the wording "requiring a >> negotiation". There is no "negotiation". Either the AS has or has not >> the "access privileges". >> The words "a negotiation of" should be deleted. >> >> This raises the point where this definition of a "Client" is using the >> wording "*access privileges*" whereas the definition of an >> "Authorization Server (AS)" >> is using the word "*privileges*". We should make both definitions >> consistent. I have a slight preference for "access privileges", but I co= uld >> also live with "privileges". >> >> Hence my proposals: >> >> * Client * >> application *operated* *by an end-user *that consumes resources >> from one or several RSs, possibly requiring *access privileges from* one >> or several ASs >> >> * Authorization Server (AS) * >> server that grants *access* privileges to a particular end-user and >> that provides them to a client in the form of an access token >> >> >> *4) Definition of a Resource Server (RS) * >> The current definition is: >> >> * Resource Server (RS) * >> Definition: server that provides operations on *protected *resource= s; >> such operations require that the client provides valid access tokens iss= ued >> by an AS >> A RS may offer both public resources and protected resources. Valid >> access tokens are only needed for protected resources. >> I propose the following definition while merging the two sentences: >> >> *Resource Server (RS) * >> server that provides operations on resources *where* protected >> operations require that the client provides *one or more* valid access >> tokens issued by *one or more ASs* >> In the above modification I added "*one or more *". I am presuming that >> GNAP will allow the presentation of more that one access token from >> different ASs >> in order to allow an end-user to perform one operation on a protected >> resource. >> >> *5) Definition of Resource Owner* >> >> The current definition is: >> * Resource Owner (RO) * >> Definition: personal or organizational entity that may grant >> privileges on resources it has authority upon >> Note: the act of granting privileges may be manual (i.e. through an >> interaction) or automatic (i.e. through predefined rules). >> >> I don't know what a "personal entity" is but I know what a "natural >> person" is. >> >> Furthermore, a Resource Owner is not granting privileges (or access >> privileges) in the same way an AS is doing. >> >> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where >> Resource Owner (RO) is defined as: >> >> responsible party for the Resource(s) >> Note 1 to entry: The Resource Owner is responsible for granting, >> denying, and revoking Access to Resource(s). >> Note 2 to entry: The responsible Resource Owner is determined by >> the concrete Resource. >> I propose: >> *Resource Owner (RO) * >> *natural person *or organizational 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) or automatic (i.e. through predefined rule= s). >> >> * 6) Definition of Access Token* >> The current definition is: >> Access token >> Definition: digitally signed data that contains specific rights >> and/or attributes >> Note 1: the access token can be issued to an end-user (usually >> requiring his authentication) and subsequently refreshed. >> The AS usually provides a method for the RO to revoke >> the privileges at any point in time. >> Note 2: an access token may act as a capability (i.e. bearer token) >> or require an additional authentication by binding to a key (i.e. bound >> token) >> The definition is fine, but not the two Notes. >> The second sentence from the Note 1 is stating: "The AS usually provides >> a method for the RO to revoke the privileges at any point in time". >> Revoking "the privileges" is different from revoking an "access token". >> The second sentence of this Note 1 which is supposed to be about access >> token is confusing. >> The privileges may be changed at any point in time using a management >> function. Access tokens can be short-lived and thus don't need to be >> revoked. >> Any call-back from a RS to an AS should be avoided in order to respect >> the user's privacy. >> >> Therefore, I propose to remove the second part of this Note 1 and to >> replace "the" by "a" at the beginning of the first sentence. >> Note 2 is stating: >> Note 2: an access token may act as a capability (i.e. bearer token= ) >> or require an additional authentication by binding to a key (i.e. bound >> token) >> From the discussion on the list, I believe that we don't consider bearer >> tokens. Note 2 should be removed. >> So my proposal is as follows: >> * Access token * >> digitally signed data that contains specific rights and/or >> attributes >> Note: an access token can be issued to an end-user (usually >> requiring his authentication) and subsequently refreshed. >> >> * 7) Definition of Grant* >> The current definition is: >> * Grant * >> Definition: (verb): to permit, as a privilege given to an end-user >> to exercise some rights and/or assert attributes during a specific >> duration >> Definition: (noun): the act of granting >> >> The words ", as a privilege given to" are unnecessary" >> I propose: >> Grant >> (verb): to permit an end-user to exercise some rights and/or *to* >> assert *some *attributes *at a specific time and *during a specific >> duration >> (noun): the act of granting >> >> >> *8) Definition of Resource* >> The current definition is: >> * Resource * >> Definition: protected API served by a RS and accessed by a client, >> if and only if a valid access token is provided >> This definition is incorrect. This definition would be fine for a >> Protected Resource. Change it into "Protected Resource": >> * Protected Resource * >> protected API served by a RS and *that can be *accessed by a >> client, if and only if a valid access token is provided >> If a definition of a Resource is needed, I propose: >> * Resource * >> public or protected resource from a RS >> >> * 9) Definition of Subject Information * >> The current definition is: >> >> *Subject Information* >> Definition: claim asserted locally by an AS about a person, organization >> or device >> Source: >> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >> (unless we plan to use something specific to GNAP) >> >> This is information returned by an AS about an end-user. >> I would thus simply propose instead: >> >> * Subject Information * >> information returned to a Client by an AS about an end-user >> >> Denis >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000d3790905b6c0add9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yes that's useful. In that case we're closer to t= he definition that we have in my previous email, than to that proposed by D= enis.=C2=A0

    Le ven. 18 d=C3=A9c. 2020 =C3=A0 18:42, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    There=E2=80=99s a subtlety about =E2=80=9Csubje= ct information=E2=80=9D that I think we need to be careful not to lose, in = that it=E2=80=99s the intersection of two different aspects of data rights = being given to the client. I=E2=80=99m not sure how best to frame this, so = apologies if this sprawls a bit:

    First, there=E2=80=99s = the dimension of how the data is transmitted to the client. This is a funda= mental difference between rights associated with an access token and data b= eing sent back directly to the client in a response message from the AS. Th= e access token is handled by the =E2=80=9Cresources=E2=80=9D request (pendi= ng proposed restructure/rename, but that=E2=80=99s the current spec). This = tells the AS the things the token can do, but as we all know a big part of = that in practice is about what data the token can be used for, and therefor= e what data the client has access to. The other information is what=E2=80= =99s sent directly to the client, and it=E2=80=99s somewhat =E2=80=9Cnew=E2= =80=9D for GNAP. OpenID Connect showed us the value of passing back an asse= rtion directly to the client, and GNAP is making this kind of =E2=80=9CDire= ct returned information=E2=80=9D a first-class citizen, to the point that m= echanisms for returning this is in our charter. This could be wrapped in an= assertion or returned as raw data, and GNAP currently allows both.

    The second dimension is what the data is about, regardles= s of how it gets back. There are lots of ways to look at this, but one fund= amental question is whether the data is :about: the end user or not. Identi= ty is far from the only use case for GNAP, but we know that it=E2=80=99s go= ing to be a driving one for many developers. And when you=E2=80=99re talkin= g about identity information, the distinction between the RQ and RO really = comes into sharp relief: are you asking about the current user, or about so= me other user on a different system, and are they the same person?

    So in total it=E2=80=99s something like this:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 Delivery Method = =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Direct =C2=A0 =C2=A0 =C2= =A0| =C2=A0Resource =C2=A0 |
    --= ---------------------------------------------+
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 End User | Subject =C2= =A0 =C2=A0 | =C2=A0UserInfo =C2=A0 |
    =C2=A0 =C2=A0 Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Information |= =C2=A0Endpoint =C2=A0 |
    =C2=A0= Subject =C2=A0-------------------------------------+
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Other =C2= =A0| ??? =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Resource =C2=A0 |
    =
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0Server API |
    ------------= -----------------------------------+

    = Is this a useful diagram and distinction to make in our discussion?

    --000000000000d3790905b6c0add9-- From nobody Fri Dec 18 10:17:51 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F75D3A0B6D for ; Fri, 18 Dec 2020 10:17:49 -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 JL6s1POoIeFf for ; Fri, 18 Dec 2020 10:17:46 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 EE00E3A0B6B for ; Fri, 18 Dec 2020 10:17:45 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id d203so3798066oia.0 for ; Fri, 18 Dec 2020 10:17:45 -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=qzMxl0KUUzYsVZrN5Jzw8CrSDh3NsaLz+sAUaHntIzY=; b=M1+0spchfBResEjAwKNpaqfEvXlpX1hRhmUrZIpB74BOryr/ZJF/0n1sDCOuT9fRr1 cKIKOla2Oy/l3fplKs/zXbZruprhtZOVV8nQvjUkEpeE8ZQC5Y0Up48b6ENnDAZxbwQS 5PMRKF2NDF2hbtbibSJdGKjVtPCXsY/g5XAs5VK1HZsnPNV+KOJ2p3uanO2JfS+ZMqmW eJQI+jLgMFIdJLKT1VRu23x8MiJKsu5kvFPdNM60DxlZhH7A1LagID4h4zoi91/kE+vz lkJVlp0dcOHUEqCCwDey3PclVoULajY5XUVRAfxO8Nq9bNOIuDxLEYu+ReeEqLG3WD4P W9cg== 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=qzMxl0KUUzYsVZrN5Jzw8CrSDh3NsaLz+sAUaHntIzY=; b=Ef+Kn0RU2XkxfNd8dLq6cYGAiZGU47tC3AUoc1+5gUH0TMcEiznmT+X0oH45TkHFEz fzquXBZdN6f9JM6HH7S0e3SjSKaOLTTiGg106APXy95FoEIa4iK8RClD4ikyKUvJf+Co Zo5jERMAB4288qwInkQhdbQ2EOJ/rokPRcTSq97HIF3pDMF+uvBkEQPe9i2h2Anjv0UN CPDOfJdSiuBuJd5yQWKoemuY4lVJBD+kvBlMQtwCY2vwKSR5qgz2bZQfQTXfkr9gIg9h bkuBKglzW/qtn6y6fsQzQx9hDaHnGzm31DdNsUhMNny51M0/AbR7svWNoFr+d9IlhUVy 8m9g== X-Gm-Message-State: AOAM532IyBuZp+UiwfJfuZaoJMzx95W4tPlSTul8H1o5mf6RtEXYvDLG gvSl44t20asgrW9/muuFQFb99ofA8mJ3aG+wTAE= X-Google-Smtp-Source: ABdhPJzrThPbvaJo1RF7ntzwq9HgCP5z/zPrABHP5Qcccj5UYoEjKnMRbNGz9UBZmi85liL7lJT8mriFrVOIqOMnRQg= X-Received: by 2002:aca:470e:: with SMTP id u14mr3628556oia.172.1608315465251; Fri, 18 Dec 2020 10:17:45 -0800 (PST) MIME-Version: 1.0 References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> In-Reply-To: From: Tom Jones Date: Fri, 18 Dec 2020 10:17:33 -0800 Message-ID: To: Fabien Imbault Cc: Denis , txauth gnap Content-Type: multipart/alternative; boundary="000000000000fe3dca05b6c11f96" Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 18 Dec 2020 18:17:49 -0000 --000000000000fe3dca05b6c11f96 Content-Type: text/plain; charset="UTF-8" you really need to focus privacy concerns on the subject. Where the end-user is not the subject, the security concerns about the end-user should be limited to the leakage from the authn, not other claims. Certainly the end user will often be the subject, but in the most general case the RO is the subject. the end-user is the authenticated entity that can pass on consent from the RO to release subject information. Peace ..tom On Fri, Dec 18, 2020 at 9:02 AM Fabien Imbault wrote: > Thanks Denis, that's a really useful feedback. I'll review that in more > detail, but something that's really not clear to me is the last one, > subject information. > > 1) is it about the end-user ? or the RO ? (as is the current definition in > V02) > 2) why do we even need to call it subject information ? For instance if > it's about the end-user, it should only be end-user information. > 3) do we want to use entity or subject in the definitions ? (cf RO for > instance). Regarding natural person vs entity we had a discussion on the > mailing list previously. > > Cheers, > Fabien > > On Fri, Dec 18, 2020 at 5:47 PM Denis wrote: > >> FYI, the wiki page is there: >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> FYI first, there is a useful web page where you can find all the ISO >> definitions as well as the text for any ISO standard (up to its definition >> section only): >> https://www.iso.org/obp >> This may provide some ideas and you will notice that a given term may be >> used in different ISO standards with a different definition. >> >> I have nine comments (each one being numbered). >> >> * 1) Current definition of AS*: >> >> The current definition is: >> >> *Authorization Server (AS) * >> Definition: server that grants privileges to a particular end-user >> and that provides them to a client in the form of an access token >> This is fine in general (but see later another comment about it), but the >> word privileges is left undefined. >> >> * 2) Definition of a privilege* >> A suggested "privilege" definition has been proposed in the wiki page: "A >> privilege is the right to perform an operation (or action) on a Resource." >> See also other def >> >> . >> In the "other def.", the term is considered to be a synonym of a >> permission. >> >> ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following : >> >> privilege >> access right >> permission >> authorization to a subject (3.15) >> to access a resource (3.14) >> >> >> Note 1 to entry: Privilege is a necessary but not sufficient >> condition for access. Access occurs when the access request is granted >> according to its access control policy. >> The access control policy is based on >> privileges and may include other environmental factors (e.g. >> time-of-day, location, etc.) >> >> Note 2 to entry: Privileges take the form of data presented by a >> subject or obtained for a subject that is used by a Policy Decision Point >> in order to grant or deny an operation >> that a subject is willing to perform on a >> resource. >> (...) >> I propose the following: >> >> *privilege*: right or attribute associated with an end-user >> with: >> *right*: ability given to an end-user to perform a given >> operation on an object under the control of a RS >> >> *attribute*: characteristics or property related to an end-user >> >> >> >> *3) Definition of a Client * The current definition is: >> *Client * >> Definition: application that consumes resources from one or several >> RSs, possibly requiring a negotiation of access privileges with one or >> several ASs >> >> Note: this specification differentiates between a specific instance >> (the client instance, identified by its public key) and the software >> running the instance >> (the client software). For some kinds of client software, >> there could be many instances of a single piece of client software. >> Example: a client can be a mobile application, a web application, >> etc. >> >> Previously, I proposed: >> >> *Client*: application used by an end-user to interact with an AS >> or a RS >> >> The current definition is missing to indicate who is operating the >> client. It is an end-user, i.e. it is not another application, nor a >> process, nor an entity. >> The definition should capture this point. >> A second point: the current definition is using the wording "requiring a >> negotiation". There is no "negotiation". Either the AS has or has not >> the "access privileges". >> The words "a negotiation of" should be deleted. >> >> This raises the point where this definition of a "Client" is using the >> wording "*access privileges*" whereas the definition of an >> "Authorization Server (AS)" >> is using the word "*privileges*". We should make both definitions >> consistent. I have a slight preference for "access privileges", but I could >> also live with "privileges". >> >> Hence my proposals: >> >> * Client * >> application *operated* *by an end-user *that consumes resources >> from one or several RSs, possibly requiring *access privileges from* one >> or several ASs >> >> * Authorization Server (AS) * >> server that grants *access* privileges to a particular end-user and >> that provides them to a client in the form of an access token >> >> >> *4) Definition of a Resource Server (RS) * >> The current definition is: >> >> * Resource Server (RS) * >> Definition: server that provides operations on *protected *resources; >> such operations require that the client provides valid access tokens issued >> by an AS >> A RS may offer both public resources and protected resources. Valid >> access tokens are only needed for protected resources. >> I propose the following definition while merging the two sentences: >> >> *Resource Server (RS) * >> server that provides operations on resources *where* protected >> operations require that the client provides *one or more* valid access >> tokens issued by *one or more ASs* >> In the above modification I added "*one or more *". I am presuming that >> GNAP will allow the presentation of more that one access token from >> different ASs >> in order to allow an end-user to perform one operation on a protected >> resource. >> >> *5) Definition of Resource Owner* >> >> The current definition is: >> * Resource Owner (RO) * >> Definition: personal or organizational entity that may grant >> privileges on resources it has authority upon >> Note: the act of granting privileges may be manual (i.e. through an >> interaction) or automatic (i.e. through predefined rules). >> >> I don't know what a "personal entity" is but I know what a "natural >> person" is. >> >> Furthermore, a Resource Owner is not granting privileges (or access >> privileges) in the same way an AS is doing. >> >> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where >> Resource Owner (RO) is defined as: >> >> responsible party for the Resource(s) >> Note 1 to entry: The Resource Owner is responsible for granting, >> denying, and revoking Access to Resource(s). >> Note 2 to entry: The responsible Resource Owner is determined by >> the concrete Resource. >> I propose: >> *Resource Owner (RO) * >> *natural person *or organizational 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) or automatic (i.e. through predefined rules). >> >> * 6) Definition of Access Token* >> The current definition is: >> Access token >> Definition: digitally signed data that contains specific rights >> and/or attributes >> Note 1: the access token can be issued to an end-user (usually >> requiring his authentication) and subsequently refreshed. >> The AS usually provides a method for the RO to revoke >> the privileges at any point in time. >> Note 2: an access token may act as a capability (i.e. bearer token) >> or require an additional authentication by binding to a key (i.e. bound >> token) >> The definition is fine, but not the two Notes. >> The second sentence from the Note 1 is stating: "The AS usually provides >> a method for the RO to revoke the privileges at any point in time". >> Revoking "the privileges" is different from revoking an "access token". >> The second sentence of this Note 1 which is supposed to be about access >> token is confusing. >> The privileges may be changed at any point in time using a management >> function. Access tokens can be short-lived and thus don't need to be >> revoked. >> Any call-back from a RS to an AS should be avoided in order to respect >> the user's privacy. >> >> Therefore, I propose to remove the second part of this Note 1 and to >> replace "the" by "a" at the beginning of the first sentence. >> Note 2 is stating: >> Note 2: an access token may act as a capability (i.e. bearer token) >> or require an additional authentication by binding to a key (i.e. bound >> token) >> From the discussion on the list, I believe that we don't consider bearer >> tokens. Note 2 should be removed. >> So my proposal is as follows: >> * Access token * >> digitally signed data that contains specific rights and/or >> attributes >> Note: an access token can be issued to an end-user (usually >> requiring his authentication) and subsequently refreshed. >> >> * 7) Definition of Grant* >> The current definition is: >> * Grant * >> Definition: (verb): to permit, as a privilege given to an end-user >> to exercise some rights and/or assert attributes during a specific >> duration >> Definition: (noun): the act of granting >> >> The words ", as a privilege given to" are unnecessary" >> I propose: >> Grant >> (verb): to permit an end-user to exercise some rights and/or *to* >> assert *some *attributes *at a specific time and *during a specific >> duration >> (noun): the act of granting >> >> >> *8) Definition of Resource* >> The current definition is: >> * Resource * >> Definition: protected API served by a RS and accessed by a client, >> if and only if a valid access token is provided >> This definition is incorrect. This definition would be fine for a >> Protected Resource. Change it into "Protected Resource": >> * Protected Resource * >> protected API served by a RS and *that can be *accessed by a >> client, if and only if a valid access token is provided >> If a definition of a Resource is needed, I propose: >> * Resource * >> public or protected resource from a RS >> >> * 9) Definition of Subject Information * >> The current definition is: >> >> *Subject Information* >> Definition: claim asserted locally by an AS about a person, organization >> or device >> Source: >> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >> (unless we plan to use something specific to GNAP) >> >> This is information returned by an AS about an end-user. >> I would thus simply propose instead: >> >> * Subject Information * >> information returned to a Client by an AS about an end-user >> >> Denis >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fe3dca05b6c11f96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    you really need to focus privacy concerns on the subject.<= div>Where the end-user is not the subject, the security concerns about the = end-user should be limited to the leakage from the authn, not other claims.=
    Certainly the end user will often=C2=A0be=C2=A0the subject, but = in the most general case the RO is the subject. the end-user is the authent= icated entity that can pass on consent from the RO to release subject infor= mation.
    Peace ..tom


    On Fri, Dec 18, 2020 at 9:02 AM Fabien Imbault <= ;fabien.imbault@gmail.com&g= t; wrote:
    Thanks Denis, that's a really useful feedback. I'll revi= ew that in more detail, but something that's really not clear to me is = the last one, subject information.

    1) is it about the en= d-user ? or the RO ? (as is the current definition in V02)
    2) why= do we even need to call it subject information ? For instance if it's = about the end-user, it should only be end-user information.=C2=A0
    3) do we want to use entity or subject in the definitions ? (cf RO for ins= tance). Regarding natural person vs entity we had a discussion on the maili= ng list previously.=C2=A0

    Cheers,
    Fabien=

    On Fri, Dec 18, 2020 at 5:47 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20

    = FYI, the wiki page is there:=C2=A0 https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ide= as and you will notice that a given term may be used in different ISO standards with a different definition. =C2= =A0

    I have nine comments (each one being numbered).

    1) Current definition of AS    : =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Authorization Server (AS) =
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: server that grants privileges to a particular end-user and= that provides them to a client in the form of an access token
    <= /span>

    This is fine in general (but see later another comment about it), but the word privileges is left undefined. =C2=A0

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page= : "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synon= ym of a permission.     =C2=A0

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

    =C2=A0=C2=A0=C2=A0=C2=A0 privilege =C2=A0
    = =C2=A0=C2=A0=C2=A0 access right
    = =C2=A0=C2=A0=C2=A0 permission
    = =C2=A0=C2=A0=C2=A0 authorization to a subject (3.15) to access a resource (3.14)
    <= /span><= br> =C2=A0=C2=A0=C2=A0 Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs w= hen the access request is granted according to its access control policy.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 T= he access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

    =C2=A0=C2=A0=C2=A0     Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 privilege: right = or attribute associated with an end-user

    with:
    =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 right: ability given t= o an end-user to perform a given operation on an object under the control of a RS

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Client
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: application that consumes reso= urces from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

    =C2=A0=C2=A0=C2=A0=C2=A0 Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
    =C2=A0=C2=A0=C2=A0     Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Client: applic= ation used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

    =C2=A0
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "acc= ess privileges".
    The words "a negotiation of<= /span>" should be deleted.

    This raises the point where this definition of a "Client" is using the wo= rding     "access privileges" whereas the definition of an "Authorization Server (AS)" =
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could = also live with "privileges". =C2=A0

    Hence my proposals:

    =C2=A0=C2=A0=C2=A0=C2=A0 Client
    =C2=A0=C2=A0=C2=A0=C2=A0 application operated     by an end-user     that consumes resources from one or s= everal RSs, possibly requiring access privileges from one or several ASs

    =C2=A0=C2=A0=C2=A0 Authorization Server (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 server that grants access privilege= s to a particular end-user and that provides them to a client in the form of an access token
    =C2=A0
    4) Definition of a Resource Server (RS)

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)

    =C2=A0=C2=A0=C2=A0=C2=A0 = Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server that provides operations on r= esources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the=C2=A0 above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
    =C2=A0
    5) Definition of Resource Owner =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0<= b> Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: personal or organizational ent= ity that may grant privileges on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural pe= rson" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsible party for the Resource(s= )
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 1 to entry: The Resource Owner = is responsible for granting, denying, and revoking Access to Resource(s).
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 2 to entry: The responsible Res= ource Owner is determined by the concrete Resource.

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 natural person or organizational en= tity that may grant or deny operations on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).


    6) Definition of Access Token     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: digitally signed data that con= tains specific rights and/or attributes
    =C2=A0=C2=A0=C2=A0     Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The AS usually p= rovides a method for the RO to revoke the privileges at any point in time.     = =C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from = the Note 1 is stating: "The AS usual= ly provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an &= quot;access token". The second sentence of this Note 1 which is supposed t= o be about access token is confusing.
    The privileges may be changed at = any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sent= ence.
    Note 2 is stating:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as foll= ows:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 digitally signed data that contains specif= ic rights and/or attributes =C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0     Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: (verb): to permit, as a privil= ege given to an end-user to exercise some rights and/or assert attributes during a specific duration
    =C2=A0=C2=A0=C2=A0     Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 (verb): to permit an end-user to exercise some rights and/or to assert so= me attributes at a specific time and during a specific duration
    =C2=A0=C2=A0=C2=A0 (noun): the act of granting
    =C2=A0
    =C2=A0
    8) Definition of Resource =C2=A0

    The current definition is= :

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definition: protected API served by = a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

    =C2=A0=C2=A0=C2=A0=C2= =A0 Protected Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 protected API served by a RS and that c= an be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 public or protected resource fr= om a RS


    9) Definition of Subject Information

    The current definition is:
    =C2=A0
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.o= rg/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propo= se instead:

    =C2=A0=C2=A0=C2=A0=C2=A0 Subject Information
    =C2=A0=C2=A0=C2=A0=C2=A0 information returned to a Client by an AS = about an end-user
    =C2=A0
    Denis

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000fe3dca05b6c11f96-- From nobody Sat Dec 19 23:46:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0C53A0B91 for ; Sat, 19 Dec 2020 23:45:57 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=DJnJDYRs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GkhGt/De Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDadvxeLsx0K for ; Sat, 19 Dec 2020 23:45:55 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC0A3A0B92 for ; Sat, 19 Dec 2020 23:45:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 75D715C00A0 for ; Sun, 20 Dec 2020 02:40:41 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 20 Dec 2020 02:40:41 -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=K0vtR1SwK4mjAv+wnWDGchiVSE8m6B826TMh3P4CoaE=; b=DJnJDYRs BzLYxhPdD5/jX1ccRI3NQM7+NyXLZ6aHMEdhJyMy4AeVjyNJL4ZXCb6n+1POF09e WcC96InxT4pSfuv0incTYq0ChzoCJVOid5IrjtrtHbUQ/fyYn81BX784fo6/PywO eZkgbB3jvDFy1vzrMzXTGjlE/ALjVFE/adDv7d8HB1OMUvvdi+/73gDZeYaGHAmS wo2oYUgzNjy15FPKc6W5FFVazZVYUMmQzIp8VxOI1zqRbskUb2oZH3sXsSh40N1s BcaPIijaJqu/fdwpWPj+8T9o8g0jSAIXnWkMRSLnFzElkk6S9Fwjo/TKOXH90D8/ QSLbBW1gAQAusw== 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=K0vtR1SwK4mjAv+wnWDGchiVSE8m6 B826TMh3P4CoaE=; b=GkhGt/DetyrC4BHKeohM7eTn58Q30Wmf+ATRQjBkVPnhH KgUaOimn5NKo/X+5jaRBKwmHePWCaD8JhFKpEkKmW5h2XC0Ck4FbjpTRgRxj8y/i YvYk7a+rixCLlV3hGDlgky7ifqxKpeorZ/u17fI4/4HFlUq6/wUfB1k0rHju35O1 KL9ChvTRi3qsxnEpBcHWWa6RaYFbgb93Xt8G5KWNEAzry8ivE50QQIh4W9w35ghp o2vAenkzenOXMyGKeojNiFo0Mh9AHwSE/eO4TJ6h+GKQzEEG+3b7ZKLaDiE3qgo+ 9r/h/VG75LJm8Pd0kBCYjHNWPDEC1fXwq5wUZY0NA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelledgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrjedtrdejuddrud dtleenucevlhhushhtvghrufhiiigvpeejnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az59-708.internal.cloudapp.net (unknown [40.70.71.109]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C2E91080057 for ; Sun, 20 Dec 2020 02:40:41 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4695457634466664610==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201220074041.3C2E91080057@mailuser.nyi.internal> Date: Sun, 20 Dec 2020 02:40:41 -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, 20 Dec 2020 07:45:58 -0000 --===============4695457634466664610== 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 (+4/-26/=F0=9F=92=AC16) 4 issues created: - Special label for access token used for continuation (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149=20 - rotation of tokens related to Continuation Request? (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/147=20 - Grant Identifier (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/146=20 - Non opaque access token (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145=20 11 issues received 16 new comments: - #149 Special label for access token used for continuation (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/149=20 - #145 Non opaque access token (6 by aaronpk, fimbault, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145=20 - #133 Privacy considerations (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133=20 - #87 Rotation of continuation access tokens (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87=20 - #84 Use of hash with unique callback URL (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/84 [Pending C= lose]=20 - #83 Additional post-interaction protocols (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/83 [Needs Tex= t] [Pending Close]=20 - #81 Interaction considerations (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/81 [Pending C= lose]=20 - #67 Continuation API artifact structure (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/67=20 - #55 Unique callback URIs (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/55 [Pending C= lose]=20 - #35 Mapping resource references (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/35 [Pending C= lose]=20 - #9 Clarify User-Code Interaction (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/9=20 26 issues closed: - Key redundancy in DPoP method https://github.com/ietf-wg-gnap/gnap-core= -protocol/issues/111 [Pending Close]=20 - Fragility of JOSE-based signature methods https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/108 [Pending Close]=20 - Detached-JWS header https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/107 [Pending Close]=20 - JWS Headers for JOSE-based signature methods https://github.com/ietf-wg= -gnap/gnap-core-protocol/issues/106 [Pending Close]=20 - HTTP PUT vs POST for rotating access tokens https://github.com/ietf-wg-= gnap/gnap-core-protocol/issues/100 [Pending Close]=20 - Use of hash with unique callback URL https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/84 [Pending Close]=20 - Additional post-interaction protocols https://github.com/ietf-wg-gnap/g= nap-core-protocol/issues/83 [Needs Text] [Pending Close]=20 - Application communication with back-end https://github.com/ietf-wg-gnap= /gnap-core-protocol/issues/82 [Needs Text] [Pending Close]=20 - Interaction considerations https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/81 [Pending Close]=20 - Response Extensions https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/80 [Pending Close]=20 - Expanding dynamic reference handles https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/76 [Pending Close]=20 - Privacy considerations of returned user information https://github.com/= ietf-wg-gnap/gnap-core-protocol/issues/74 [Pending Close]=20 - Post interaction callback nonce https://github.com/ietf-wg-gnap/gnap-co= re-protocol/issues/73 [Pending Close]=20 - Guidance for Grant Request Extensions https://github.com/ietf-wg-gnap/g= nap-core-protocol/issues/65 [Pending Close]=20 - Provide guidance for defining new interactions https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/61 [Pending Close]=20 - Create more examples of interaction modes https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/52 [Pending Close]=20 - Fetchable keys https://github.com/ietf-wg-gnap/gnap-core-protocol/issue= s/47 [Needs Text] [Pending Close]=20 - Instance Identifier https://github.com/ietf-wg-gnap/gnap-core-protocol/= issues/46 [Pending Close]=20 - Requesting resources by reference https://github.com/ietf-wg-gnap/gnap-= core-protocol/issues/36 [Pending Close]=20 - Mapping resource references https://github.com/ietf-wg-gnap/gnap-core-p= rotocol/issues/35 [Pending Close]=20 - Alignment with RAR https://github.com/ietf-wg-gnap/gnap-core-protocol/i= ssues/34 [Pending Close]=20 - Non-role protocol elements https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/issues/33 [Pending Close]=20 - Structure of the spec https://github.com/ietf-wg-gnap/gnap-core-protoco= l/issues/30 [Pending Close]=20 - Continuation API artifact structure https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/67=20 - Splitting the "claims" request https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/63 [Pending Close]=20 - Including OpenID Connect claims https://github.com/ietf-wg-gnap/gnap-co= re-protocol/issues/64 [Needs Text] [Pending Close]=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+3/-4/=F0=9F=92=AC2) 3 pull requests submitted: - added workflow to publish rendered drafts (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/151 [Editorial]= =20 - Remove closed issues from draft text. (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/150=20 - add verify pr label test (by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/148=20 2 pull requests received 2 new comments: - #151 added workflow to publish rendered drafts (1 by github-actions) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/151 [Editorial]= =20 - #143 Replace 'MUST ... if possible' with SHOULD. (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/143=20 4 pull requests merged: - added workflow to publish rendered drafts https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/151 [Editorial]= =20 - Make access token mandatory for continuation API calls. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 [Pending Me= rge]=20 - drop examples of requesting OIDC claims https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/140 [Pending Me= rge]=20 - add verify pr label test https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/148 [Pending Me= rge]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============4695457634466664610== 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 December 20, 2020

    Events without label "editorial"

    Issues

    ietf-wg-gnap/core-protocol (+4/-26/=F0=9F=92=AC16)

    4 issues created:

    11 issues received 16 new comments:

    26 issues closed:

    Pull requests

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

    3 pull requests submitted:

    2 pull requests received 2 new comments:

    4 pull requests merged:

    Repositories tracked by this digest:

    --===============4695457634466664610==-- From nobody Mon Dec 21 00:43:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A736A3A0F9D for ; Mon, 21 Dec 2020 00:43: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 x1ap6-FGr0VG for ; Mon, 21 Dec 2020 00:43:24 -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 806433A0F74 for ; Mon, 21 Dec 2020 00:43:24 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id n4so8116227iow.12 for ; Mon, 21 Dec 2020 00:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dc8gYhIkBHwlw8C3qL75eQ8SQtA5unKq02vd0AOfoJU=; b=n6bykNEmERL0kDKOWBkQU9ibsFLTIvaE2Q0lg1ksAM9ToqPwNI3MgaYsiarJXS/Rtf bEk+YxdcOUPVTEa7pRRWZZzK7iXje9UQk5e6zKoxffQmwmqrwOJC3OJ5hlACSM+PzueL aparJWwY2fzpqcJn75FmuDP/KnNKvGIJ9uvtYCxm/Cysiukp7zS+KIAF0Ty64G1Mvs/m cmOtQPeRAS67WvmSUSIeSm6/Xdqb64Ej08pQ1AnK2RYYiWrB2hDlUsSkZszA/5/UbUKT APcKIzWzcVIU82PoW2e7ocwXIaeztywV1yJe16taSNtOm3kP9r48+O4di+4GBigwjhyh 10Eg== 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=Dc8gYhIkBHwlw8C3qL75eQ8SQtA5unKq02vd0AOfoJU=; b=piew+kBhUcG77T3zYydCpW33wmNRRNS5FHt5nCFmnE3g9YDBRIPk+8vmpZrXV6sC2K JhSgbnzNNk3QZrbfeowEPYuCrsdiMZTPcF81pvumoyLeVYl54FH+QmD+uuB8zxbOf+4h ffUDtcHxNe16vO/zxeVvmJlIIRyE2mIJbkCN7RHeTuD1pJCZRneocsmuUrjwpipgBhf2 nGEAQl2nOxUDYXtvGCy+cZQWMv+9MIiF+o0lgKugGFGNhOB7vb9DJtqZ4cD9P/HY4UFO j7fJbkO62/3UHsfXz+wuaE49YdkNPFFotY9uZuA0zCKSG12TfvYskYIhP2Mw6LJXJXOv 4jYA== X-Gm-Message-State: AOAM531gnOq9utmlZP79Pox77WMk90umm5iuZYJDF8uvzJUi1B0D97IW 9kIwC/K/4VnhhbfzNzk25Ux6Z8wwEHyxpDT/UBfb5RlLKv5G5Q== X-Google-Smtp-Source: ABdhPJw68Yo3ncxInqTVydTjEuarU+LF92GxymLR+uQX4QRMjT2l0q8PUZUmHRV7m5KxhWH/0KqskxRxl+NIKsmoSa0= X-Received: by 2002:a02:9f8b:: with SMTP id a11mr14190707jam.108.1608540203490; Mon, 21 Dec 2020 00:43:23 -0800 (PST) MIME-Version: 1.0 References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> In-Reply-To: From: Fabien Imbault Date: Mon, 21 Dec 2020 09:43:10 +0100 Message-ID: To: Tom Jones Cc: Denis , txauth gnap Content-Type: multipart/alternative; boundary="0000000000006fdbcd05b6f573e3" Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 21 Dec 2020 08:43:28 -0000 --0000000000006fdbcd05b6f573e3 Content-Type: text/plain; charset="UTF-8" Hi, Terminology is probably not the right place to define the requirements. I suggest we keep "subject" for now (and use it as a replacement of "entity" in the RO definition), and have a more detailed discussion about how we support privacy in general. If we later see that we need to restrict the definition because we always have the requirement, we can still do that. Fabien On Fri, Dec 18, 2020 at 7:17 PM Tom Jones wrote: > you really need to focus privacy concerns on the subject. > Where the end-user is not the subject, the security concerns about the > end-user should be limited to the leakage from the authn, not other claims. > Certainly the end user will often be the subject, but in the most general > case the RO is the subject. the end-user is the authenticated entity that > can pass on consent from the RO to release subject information. > Peace ..tom > > > On Fri, Dec 18, 2020 at 9:02 AM Fabien Imbault > wrote: > >> Thanks Denis, that's a really useful feedback. I'll review that in more >> detail, but something that's really not clear to me is the last one, >> subject information. >> >> 1) is it about the end-user ? or the RO ? (as is the current definition >> in V02) >> 2) why do we even need to call it subject information ? For instance if >> it's about the end-user, it should only be end-user information. >> 3) do we want to use entity or subject in the definitions ? (cf RO for >> instance). Regarding natural person vs entity we had a discussion on the >> mailing list previously. >> >> Cheers, >> Fabien >> >> On Fri, Dec 18, 2020 at 5:47 PM Denis wrote: >> >>> FYI, the wiki page is there: >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >>> FYI first, there is a useful web page where you can find all the ISO >>> definitions as well as the text for any ISO standard (up to its definition >>> section only): >>> https://www.iso.org/obp >>> This may provide some ideas and you will notice that a given term may be >>> used in different ISO standards with a different definition. >>> >>> I have nine comments (each one being numbered). >>> >>> * 1) Current definition of AS*: >>> >>> The current definition is: >>> >>> *Authorization Server (AS) * >>> Definition: server that grants privileges to a particular end-user >>> and that provides them to a client in the form of an access token >>> This is fine in general (but see later another comment about it), but >>> the word privileges is left undefined. >>> >>> * 2) Definition of a privilege* >>> A suggested "privilege" definition has been proposed in the wiki page: "A >>> privilege is the right to perform an operation (or action) on a Resource." >>> See also other def >>> >>> . >>> In the "other def.", the term is considered to be a synonym of a >>> permission. >>> >>> ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following : >>> >>> privilege >>> access right >>> permission >>> authorization to a subject (3.15) >>> to access a resource (3.14) >>> >>> >>> Note 1 to entry: Privilege is a necessary but not sufficient >>> condition for access. Access occurs when the access request is granted >>> according to its access control policy. >>> The access control policy is based on >>> privileges and may include other environmental factors (e.g. >>> time-of-day, location, etc.) >>> >>> Note 2 to entry: Privileges take the form of data presented by a >>> subject or obtained for a subject that is used by a Policy Decision Point >>> in order to grant or deny an operation >>> that a subject is willing to perform on a >>> resource. >>> (...) >>> I propose the following: >>> >>> *privilege*: right or attribute associated with an end-user >>> with: >>> *right*: ability given to an end-user to perform a given >>> operation on an object under the control of a RS >>> >>> *attribute*: characteristics or property related to an end-user >>> >>> >>> >>> *3) Definition of a Client * The current definition is: >>> *Client * >>> Definition: application that consumes resources from one or several >>> RSs, possibly requiring a negotiation of access privileges with one or >>> several ASs >>> >>> Note: this specification differentiates between a specific instance >>> (the client instance, identified by its public key) and the software >>> running the instance >>> (the client software). For some kinds of client software, >>> there could be many instances of a single piece of client software. >>> Example: a client can be a mobile application, a web application, >>> etc. >>> >>> Previously, I proposed: >>> >>> *Client*: application used by an end-user to interact with an AS >>> or a RS >>> >>> The current definition is missing to indicate who is operating the >>> client. It is an end-user, i.e. it is not another application, nor a >>> process, nor an entity. >>> The definition should capture this point. >>> A second point: the current definition is using the wording "requiring >>> a negotiation". There is no "negotiation". Either the AS has or has not >>> the "access privileges". >>> The words "a negotiation of" should be deleted. >>> >>> This raises the point where this definition of a "Client" is using the >>> wording "*access privileges*" whereas the definition of an >>> "Authorization Server (AS)" >>> is using the word "*privileges*". We should make both definitions >>> consistent. I have a slight preference for "access privileges", but I could >>> also live with "privileges". >>> >>> Hence my proposals: >>> >>> * Client * >>> application *operated* *by an end-user *that consumes resources >>> from one or several RSs, possibly requiring *access privileges from* >>> one or several ASs >>> >>> * Authorization Server (AS) * >>> server that grants *access* privileges to a particular end-user >>> and that provides them to a client in the form of an access token >>> >>> >>> *4) Definition of a Resource Server (RS) * >>> The current definition is: >>> >>> * Resource Server (RS) * >>> Definition: server that provides operations on *protected *resources; >>> such operations require that the client provides valid access tokens issued >>> by an AS >>> A RS may offer both public resources and protected resources. Valid >>> access tokens are only needed for protected resources. >>> I propose the following definition while merging the two sentences: >>> >>> *Resource Server (RS) * >>> server that provides operations on resources *where* protected >>> operations require that the client provides *one or more* valid access >>> tokens issued by *one or more ASs* >>> In the above modification I added "*one or more *". I am presuming >>> that GNAP will allow the presentation of more that one access token from >>> different ASs >>> in order to allow an end-user to perform one operation on a protected >>> resource. >>> >>> *5) Definition of Resource Owner* >>> >>> The current definition is: >>> * Resource Owner (RO) * >>> Definition: personal or organizational entity that may grant >>> privileges on resources it has authority upon >>> Note: the act of granting privileges may be manual (i.e. through an >>> interaction) or automatic (i.e. through predefined rules). >>> >>> I don't know what a "personal entity" is but I know what a "natural >>> person" is. >>> >>> Furthermore, a Resource Owner is not granting privileges (or access >>> privileges) in the same way an AS is doing. >>> >>> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where >>> Resource Owner (RO) is defined as: >>> >>> responsible party for the Resource(s) >>> Note 1 to entry: The Resource Owner is responsible for granting, >>> denying, and revoking Access to Resource(s). >>> Note 2 to entry: The responsible Resource Owner is determined by >>> the concrete Resource. >>> I propose: >>> *Resource Owner (RO) * >>> *natural person *or organizational 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) or automatic (i.e. through predefined rules). >>> >>> * 6) Definition of Access Token* >>> The current definition is: >>> Access token >>> Definition: digitally signed data that contains specific rights >>> and/or attributes >>> Note 1: the access token can be issued to an end-user (usually >>> requiring his authentication) and subsequently refreshed. >>> The AS usually provides a method for the RO to revoke >>> the privileges at any point in time. >>> Note 2: an access token may act as a capability (i.e. bearer token) >>> or require an additional authentication by binding to a key (i.e. bound >>> token) >>> The definition is fine, but not the two Notes. >>> The second sentence from the Note 1 is stating: "The AS usually >>> provides a method for the RO to revoke the privileges at any point in time". >>> Revoking "the privileges" is different from revoking an "access token". >>> The second sentence of this Note 1 which is supposed to be about access >>> token is confusing. >>> The privileges may be changed at any point in time using a management >>> function. Access tokens can be short-lived and thus don't need to be >>> revoked. >>> Any call-back from a RS to an AS should be avoided in order to respect >>> the user's privacy. >>> >>> Therefore, I propose to remove the second part of this Note 1 and to >>> replace "the" by "a" at the beginning of the first sentence. >>> Note 2 is stating: >>> Note 2: an access token may act as a capability (i.e. bearer >>> token) or require an additional authentication by binding to a key >>> (i.e. bound token) >>> From the discussion on the list, I believe that we don't consider bearer >>> tokens. Note 2 should be removed. >>> So my proposal is as follows: >>> * Access token * >>> digitally signed data that contains specific rights and/or >>> attributes >>> Note: an access token can be issued to an end-user (usually >>> requiring his authentication) and subsequently refreshed. >>> >>> * 7) Definition of Grant* >>> The current definition is: >>> * Grant * >>> Definition: (verb): to permit, as a privilege given to an end-user >>> to exercise some rights and/or assert attributes during a specific >>> duration >>> Definition: (noun): the act of granting >>> >>> The words ", as a privilege given to" are unnecessary" >>> I propose: >>> Grant >>> (verb): to permit an end-user to exercise some rights and/or *to* >>> assert *some *attributes *at a specific time and *during a specific >>> duration >>> (noun): the act of granting >>> >>> >>> *8) Definition of Resource* >>> The current definition is: >>> * Resource * >>> Definition: protected API served by a RS and accessed by a client, >>> if and only if a valid access token is provided >>> This definition is incorrect. This definition would be fine for a >>> Protected Resource. Change it into "Protected Resource": >>> * Protected Resource * >>> protected API served by a RS and *that can be *accessed by a >>> client, if and only if a valid access token is provided >>> If a definition of a Resource is needed, I propose: >>> * Resource * >>> public or protected resource from a RS >>> >>> * 9) Definition of Subject Information * >>> The current definition is: >>> >>> *Subject Information* >>> Definition: claim asserted locally by an AS about a person, >>> organization or device >>> Source: >>> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >>> (unless we plan to use something specific to GNAP) >>> >>> This is information returned by an AS about an end-user. >>> I would thus simply propose instead: >>> >>> * Subject Information * >>> information returned to a Client by an AS about an end-user >>> >>> Denis >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000006fdbcd05b6f573e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    Terminology is probably not t= he right place to define the requirements.

    I sugge= st we keep "subject" for now (and use it as a replacement of &quo= t;entity" in the RO definition), and have a more detailed=C2=A0discuss= ion about how we support privacy in general. If we later see that we need t= o restrict the definition because we always have the requirement, we can st= ill do that.=C2=A0

    Fabien

    On Fri, Dec 18, 202= 0 at 7:17 PM Tom Jones <= thomasclinganjones@gmail.com> wrote:
    you really need to focus priva= cy concerns on the subject.
    Where the end-user is not the subject, the = security concerns about the end-user should be limited to the leakage from = the authn, not other claims.
    Certainly the end user will often=C2= =A0be=C2=A0the subject, but in the most general case the RO is the subject.= the end-user is the authenticated entity that can pass on consent from the= RO to release subject information.
    =
    Peace ..tom

    On Fri, = Dec 18, 2020 at 9:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Than= ks Denis, that's a really useful feedback. I'll review that in more= detail, but something that's really not clear to me is the last one, s= ubject information.

    1) is it about the end-user ? or the= RO ? (as is the current definition in V02)
    2) why do we even nee= d to call it subject information ? For instance if it's about the end-u= ser, it should only be end-user information.=C2=A0
    3) do we want = to use entity or subject in the definitions ? (cf RO for instance). Regardi= ng natural person vs entity we had a discussion on the mailing list previou= sly.=C2=A0

    Cheers,
    Fabien
    On Fri, D= ec 18, 2020 at 5:47 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20

    = FYI, the wiki page is there:=C2=A0 https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ide= as and you will notice that a given term may be used in different ISO standards with a different definition. =C2= =A0

    I have nine comments (each one being numbered).

    1) Current definition of AS    : =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Authorization Server (AS) =
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: server that grants privileges to a particular end-user and= that provides them to a client in the form of an access token
    <= /span>

    This is fine in general (but see later another comment about it), but the word privileges is left undefined. =C2=A0

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page= : "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synon= ym of a permission.     =C2=A0

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

    =C2=A0=C2=A0=C2=A0=C2=A0 privilege =C2=A0
    = =C2=A0=C2=A0=C2=A0 access right
    = =C2=A0=C2=A0=C2=A0 permission
    = =C2=A0=C2=A0=C2=A0 authorization to a subject (3.15) to access a resource (3.14)
    <= /span><= br> =C2=A0=C2=A0=C2=A0 Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs w= hen the access request is granted according to its access control policy.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 T= he access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

    =C2=A0=C2=A0=C2=A0     Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 privilege: right = or attribute associated with an end-user

    with:
    =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 right: ability given t= o an end-user to perform a given operation on an object under the control of a RS

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Client
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: application that consumes reso= urces from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

    =C2=A0=C2=A0=C2=A0=C2=A0 Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
    =C2=A0=C2=A0=C2=A0     Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Client: applic= ation used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

    =C2=A0
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "acc= ess privileges".
    The words "a negotiation of<= /span>" should be deleted.

    This raises the point where this definition of a "Client" is using the wo= rding     "access privileges" whereas the definition of an "Authorization Server (AS)" =
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could = also live with "privileges". =C2=A0

    Hence my proposals:

    =C2=A0=C2=A0=C2=A0=C2=A0 Client
    =C2=A0=C2=A0=C2=A0=C2=A0 application operated     by an end-user     that consumes resources from one or s= everal RSs, possibly requiring access privileges from one or several ASs

    =C2=A0=C2=A0=C2=A0 Authorization Server (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 server that grants access privilege= s to a particular end-user and that provides them to a client in the form of an access token
    =C2=A0
    4) Definition of a Resource Server (RS)

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)

    =C2=A0=C2=A0=C2=A0=C2=A0 = Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server that provides operations on r= esources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the=C2=A0 above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
    =C2=A0
    5) Definition of Resource Owner =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0<= b> Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: personal or organizational ent= ity that may grant privileges on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural pe= rson" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsible party for the Resource(s= )
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 1 to entry: The Resource Owner = is responsible for granting, denying, and revoking Access to Resource(s).
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 2 to entry: The responsible Res= ource Owner is determined by the concrete Resource.

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 natural person or organizational en= tity that may grant or deny operations on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).


    6) Definition of Access Token     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: digitally signed data that con= tains specific rights and/or attributes
    =C2=A0=C2=A0=C2=A0     Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The AS usually p= rovides a method for the RO to revoke the privileges at any point in time.     = =C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from = the Note 1 is stating: "The AS usual= ly provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an &= quot;access token". The second sentence of this Note 1 which is supposed t= o be about access token is confusing.
    The privileges may be changed at = any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sent= ence.
    Note 2 is stating:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as foll= ows:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 digitally signed data that contains specif= ic rights and/or attributes =C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0     Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: (verb): to permit, as a privil= ege given to an end-user to exercise some rights and/or assert attributes during a specific duration
    =C2=A0=C2=A0=C2=A0     Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 (verb): to permit an end-user to exercise some rights and/or to assert so= me attributes at a specific time and during a specific duration
    =C2=A0=C2=A0=C2=A0 (noun): the act of granting
    =C2=A0
    =C2=A0
    8) Definition of Resource =C2=A0

    The current definition is= :

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definition: protected API served by = a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

    =C2=A0=C2=A0=C2=A0=C2= =A0 Protected Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 protected API served by a RS and that c= an be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 public or protected resource fr= om a RS


    9) Definition of Subject Information

    The current definition is:
    =C2=A0
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.o= rg/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propo= se instead:

    =C2=A0=C2=A0=C2=A0=C2=A0 Subject Information
    =C2=A0=C2=A0=C2=A0=C2=A0 information returned to a Client by an AS = about an end-user
    =C2=A0
    Denis

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000006fdbcd05b6f573e3-- From nobody Mon Dec 21 03:06:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B64F3A10BA for ; Mon, 21 Dec 2020 03:06:41 -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 (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nc83Iep96VFr for ; Mon, 21 Dec 2020 03:06:39 -0800 (PST) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 A29B73A10C3 for ; Mon, 21 Dec 2020 03:06:39 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id w1so12827874ejf.11 for ; Mon, 21 Dec 2020 03:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=IcnDh1bv42sQ2Ty5MobdDCxOX/TXDa264z/TJLKhh1Y=; b=dmAcnCaiNp7sJDKXkqANRO/rlRjX2R4NsWmjEon41BGQ1vfGRhEpcQninen50ZgLaN UYFeEWQ+M1DXlZHNO9ZWAZwK/4wuBcY/PGBSu4ei1+djW74w7AuorsSzUDCxfNYaaphb IVKqPf7QGitD1JfSh2yfj0CyrnlWM9Cr577Xc= 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=IcnDh1bv42sQ2Ty5MobdDCxOX/TXDa264z/TJLKhh1Y=; b=cUj1eX4qZ5YKlHJ6u6x9b42NU5T5rnnFaXTXBOcL94/xh3NyGWrAvQsBiSue4xarfH LX1sJ2asRROey6nYgXjifR08Vfx421dTzhiVYnPiIuPrmx0za5qvys57jaaQt9u+3MhL V8pBquamNkvejBRhjYGhczWC/QUsFgJAk6deFs/N0UiIHuhMCVFcxt9Ie6syA86QAJNI RLGrc5GkVSHUsUMjjig6A8yRXpihrGwE3J3zPLciHo106WS6WRjGrnS8W/gHLi04LtQi QQYDeWpVL4k9IuJS4m1o9IJWAXszGqXPCHNT7OUtQXQkIG0ZqRwgAmxaD5nejq1WDnpL T93w== X-Gm-Message-State: AOAM533ymA7Hx2bVgVDs63QDiFfmb/fJGdXahiB/ScnqXIRxLJLANEQo PUnzWWpzsgBHv1MHJGpZrLC36Rt6WloE/513MrN20gYI9o6L8i9ENG0beopK5qc2KhKhDSuSesu j/NeUtRl9JP47UlcwfRGCEPVkMg== X-Google-Smtp-Source: ABdhPJznueJpLbR0vKP5pvpYv3l9PvOnoP5ari5hqMzW9PV+otruVgp8mlZlNySAaMw5Q8hVjYQ5r/YY672KbIsmAUo= X-Received: by 2002:a17:906:38c8:: with SMTP id r8mr15016205ejd.39.1608548797455; Mon, 21 Dec 2020 03:06:37 -0800 (PST) MIME-Version: 1.0 From: Dave Tonge Date: Mon, 21 Dec 2020 12:06:26 +0100 Message-ID: To: GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000ad3b6805b6f7734e" Archived-At: Subject: [GNAP] Sessions and Post Interaction Completion 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, 21 Dec 2020 11:06:42 -0000 --000000000000ad3b6805b6f7734e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I may have missed something - but I'm trying to follow the params involved in the "Post-Interaction Completion" section. As I understand the flow is: 1. RC indicates it can accept "callback" and provides a nonce and a uri 2. AS indicates the callback will be used and provides a nonce ...interaction happens... 3. AS either redirects the user or does a POST to the RC uri with a new param: `interact_ref` and a hash of the RC nonce, AS nonce and interact_ref= . 4. RC validates hash and calls AS with `interact_ref` (and access token) If the uri provided by the RC isn't unique then I think the RC nonce should be included in the params. The hash will still be secure as the AS nonce will not be revealed, but this allows the RC to take actions on the request before validating the hash. For example: 1. In some redirect based systems the `state` param in OAuth 2 is used to redirect the user appropriately (within the RC's systems), prior to being confirmed by the matching `state` in the session. 2. In the "Direct HTTP Request Callback" mode, I don't understand how the RC is supposed to know which interaction the callback is for (assuming its not a dynamic uri)? Additionally it would be good to see some analysis of why the hash is needed. My opinion is that where possible validation should occur at the AS rather than the RC. Do we really need the hash? In OAuth 2 getting access to the `code` enables a lot of attacks, I don't the same is true for the `interact_ref`. The `interact_ref` will be bound to the access_token returned from the initial grant request. --=20 Dave Tonge --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000ad3b6805b6f7734e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi

    I may have missed something - but I'= m trying to follow the params involved in the "Post-Interaction Comple= tion" section.

    As I understand the flow is:
    1. RC = indicates it can accept "callback" and provides a nonce and a uri=
    2. AS indicates the callback will be used and provides a nonce
    <= div class=3D"gmail_default" style=3D"font-family:trebuchet ms,sans-serif">.= ..interaction happens...
    3. AS either redirects the user or does a POS= T to the RC uri with a new param: `interact_ref` and a hash of the RC nonce= , AS nonce and interact_ref.
    4. RC validates hash and calls AS with `i= nteract_ref` (and access token)

    If the=C2=A0uri provided by = the RC isn't unique then I think the RC nonce should be included in the= params. The hash will still be secure as the AS nonce will not be revealed= , but this allows the RC to take actions on the request before validating t= he hash.

    For example:
    1. In some redirect based systems= the `state` param in OAuth 2 is used to redirect the user appropriately (w= ithin the RC's systems), prior to being confirmed by the matching `stat= e` in the session.=C2=A0

    2. In the "Direct HTTP Reques= t Callback" mode, I don't understand how the RC is supposed to kno= w which interaction the callback is for (assuming its not a dynamic uri)?

    Additionally it would be good to see some analysis of why the= hash is needed. My opinion is that where possible validation should occur = at the AS rather than the RC. Do we really need the hash? In OAuth 2 gettin= g access to the `code` enables a lot of attacks, I don't the same is tr= ue for the `interact_ref`. The `interact_ref` will be bound to the access_t= oken returned from the initial grant request.

    --
    Dave Tonge


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

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


    --000000000000ad3b6805b6f7734e-- From nobody Mon Dec 21 03:13:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEA93A10D4 for ; Mon, 21 Dec 2020 03:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inbdcGp1eBtM for ; Mon, 21 Dec 2020 03:13:48 -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 A8B8C3A10D3 for ; Mon, 21 Dec 2020 03:13:47 -0800 (PST) Received: from [192.168.1.11] ([90.79.54.243]) by mwinf5d52 with ME id 6zDi2401K5Eqqlm03zDjDh; Mon, 21 Dec 2020 12:13:44 +0100 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 21 Dec 2020 12:13:44 +0100 X-ME-IP: 90.79.54.243 To: Fabien Imbault , Justin Richer Cc: txauth gnap References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> <0E0E3DD6-24E0-47BE-8441-9426C1FB7AEE@mit.edu> From: Denis Message-ID: <8d493c75-0970-1df8-dab2-29b78bba06a6@free.fr> Date: Mon, 21 Dec 2020 12:13:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FA58FC0B0185146919EC1FC6" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 21 Dec 2020 11:13:52 -0000 This is a multi-part message in MIME format. --------------FA58FC0B0185146919EC1FC6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, I read your explanations several times and I must admit that I fail to grasp your point of view. From my point of view, there are two kinds of information that can be sent back by an AS to a Client: 1.    an access token that contains in particular a subset of the claims about an end-user (among other data), or 2.    information about the end-user. Let us focus on the second case. The AS holds personal information about the end-user but this does not means that all that information can/will become a claim that will be included into an access token. In particular, the end-user information may contain data that will never be included into an access token. As a conclusion, the claims about an end-user are a subset of the end-user information. In other words, a “claim” is NOT any statement made by an potentially authoritative source, the AS. In Europe, we now have in force the GDPR (General Data Protection Regulation), i.e. the REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC. It is available in 24 languages here: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679 Article 15 which is about the "Right of access by the data subject" states: 1. The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data and the following information: (a)    the purposes of the processing; (b)    the categories of personal data concerned; (...) Let us use an example to illustrate this. Some banks require to know the marital name of the mother of the end-user or/and her first name. It is an information that the end-user knows and will not forget. Such marital name is not intended to be included into an access token. It is used to authenticate the end-user when he/she is making a phone call to the bank. If such information has been collected, the marital name of the mother of the end-user may be returned in the "information about the end-user". The information retuned by an AS to a Client about the end-user should include at least: (a) the categories of personal data concerned, (b) the personal data and (c) the purposes of the processing (e.g. may be included as a claim into an access token). So I believe that my proposal is still adequate: end-user information: information returned to a Client by an AS about an end-user In the core of the document, we may provide more explanations. Denis > Yes that's useful. In that case we're closer to the definition that we > have in my previous email, than to that proposed by Denis. > > Le ven. 18 déc. 2020 à 18:42, Justin Richer > a écrit : > > There’s a subtlety about “subject information” that I think we > need to be careful not to lose, in that it’s the intersection of > two different aspects of data rights being given to the client. > I’m not sure how best to frame this, so apologies if this sprawls > a bit: > > First, there’s the dimension of how the data is transmitted to the > client. This is a fundamental difference between rights associated > with an access token and data being sent back directly to the > client in a response message from the AS. The access token is > handled by the “resources” request (pending proposed > restructure/rename, but that’s the current spec). This tells the > AS the things the token can do, but as we all know a big part of > that in practice is about what data the token can be used for, and > therefore what data the client has access to. The other > information is what’s sent directly to the client, and it’s > somewhat “new” for GNAP. OpenID Connect showed us the value of > passing back an assertion directly to the client, and GNAP is > making this kind of “Direct returned information” a first-class > citizen, to the point that mechanisms for returning this is in our > charter. This could be wrapped in an assertion or returned as raw > data, and GNAP currently allows both. > > The second dimension is what the data is about, regardless of how > it gets back. There are lots of ways to look at this, but one > fundamental question is whether the data is :about: the end user > or not. Identity is far from the only use case for GNAP, but we > know that it’s going to be a driving one for many developers. And > when you’re talking about identity information, the distinction > between the RQ and RO really comes into sharp relief: are you > asking about the current user, or about some other user on a > different system, and are they the same person? > > So in total it’s something like this: > >                    | Delivery Method       | >                    |                   | >                    | Direct      |  Resource   | > -----------------------------------------------+ >           End User | Subject     |  UserInfo   | >     Data           | Information |  Endpoint   | >  Subject  -------------------------------------+ >             Other  | ???     |  Resource   | >                    |     |  Server API | > -----------------------------------------------+ > > Is this a useful diagram and distinction to make in our discussion? > > Also for what it’s worth, the OpenID Connect “claims” language > would cover everything in that square. It’s primarily about the > end user, but doesn’t have to be as the OIDC spec itself stats > that it provides methods for "Claims about the End-User and the > Authentication event”. In other words, a “claim” is any statement > made by an potentially authoritative source, the AS. > >  — Justin > >> On Dec 18, 2020, at 12:02 PM, Fabien Imbault >> > wrote: >> >> Thanks Denis, that's a really useful feedback. I'll review that >> in more detail, but something that's really not clear to me is >> the last one, subject information. >> >> 1) is it about the end-user ? or the RO ? (as is the current >> definition in V02) >> 2) why do we even need to call it subject information ? For >> instance if it's about the end-user, it should only be end-user >> information. >> 3) do we want to use entity or subject in the definitions ? (cf >> RO for instance). Regarding natural person vs entity we had a >> discussion on the mailing list previously. >> >> Cheers, >> Fabien >> >> On Fri, Dec 18, 2020 at 5:47 PM Denis > > wrote: >> >> >> FYI, the wiki page is >> there:https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> >> >> >> FYI first, there is a useful web page where you can >> find all the ISO definitions as well as the text for >> any ISO standard (up to its definition section only): >> https://www.iso.org/obp >> >> >> This may provide some ideas and you will notice that a >> given term may be used in different ISO standards with >> a different definition. >> >> I have nine comments (each one being numbered). >> _ >> 1) Current definition of AS_: >> >> The current definition is: >> >> *Authorization Server (AS) * >>      Definition: server that grants privileges to a >> particular end-user and that provides them to a client >> in the form of an access token >> >> >> This is fine in general (but see later another comment >> about it), but the word privileges is left undefined. >> _ >> 2) Definition of a privilege__ >> _ >> >> >> A suggested "privilege" definition has been proposed in >> the wiki page: "A privilege is the right to perform an >> operation (or action) on a Resource." See also other >> def >> >> . >> In the "other def.", the term is considered to be a >> synonym of a permission. >> >> ISO/IEC 29146:2016(en), 3.8 (very long) definition is >> the following : >> >>      privilege >> access right >> permission >> authorization to a subject (3.15) >> to access a >> resource (3.14) >> >> Note 1 to entry: Privilege is a necessary but not >> sufficient condition for access. Access occurs when the >> access request is granted according to its access >> control policy. >>                               The access control policy >> is based on privileges and may include other >> environmental factors (e.g. time-of-day, location, etc.) >> >> Note 2 to entry: Privileges take the form of data >> presented by a subject or obtained for a subject that >> is used by a Policy Decision Point in order to grant or >> deny an operation >>                               that a subject is willing >> to perform on a resource. >> (...) >> >> >> I propose the following: >> >> *privilege*: right or attribute associated with an >> end-user >> >> >> with: >> *right*: ability given to an end-user to perform a >> given operation on an object under the control of a RS >> >> *attribute*: characteristics or property related to an >> end-user >> >> __ >> >> >> _3) Definition of a Client >> >> _ >> >> >> The current definition is: >> >> >> *Client * >>      Definition: application that consumes resources >> from one or several RSs, possibly requiring a >> negotiation of access privileges with one or several ASs >> >>      Note: this specification differentiates between a >> specific instance (the client instance, identified by >> its public key) and the software running the instance >>               (the client software). For some kinds of >> client software, there could be many instances of a >> single piece of client software. >> Example: a client can be a mobile application, a web >> application, etc. >> >> Previously, I proposed: >> >> *Client*: application used by an end-user to interact >> with an AS or a RS >> >> The current definition is missing to indicate who is >> operating the client. It is an end-user, i.e. it is not >> another application, nor a process, nor an entity. >> The definition should capture this point. >> >> >> >> A second point: the current definition is using the >> wording "requiring a negotiation". There is no >> "negotiation". Either the AS has or has not the "access >> privileges". >> The words "a negotiation of" should be deleted. >> >> This raises the point where this definition of a >> "Client" is using the wording "/access privileges/" >> whereas the definition of an "Authorization Server (AS)" >> is using the word "/privileges/". We should make both >> definitions consistent. I have a slight preference for >> "access privileges", but I could also live with >> "privileges". >> >> Hence my proposals: >> >> *     Client * >>      application /operated/ /by an end-user /that >> consumes resources from one or several RSs, possibly >> requiring /access privileges from/ one or several ASs >> * >> **    Authorization Server (AS) * >>      server that grants /access/ privileges to a >> particular end-user and that provides them to a client >> in the form of an access token >> >> _4) Definition of a Resource Server (RS) >> _ >> The current definition is: >> * >> **     Resource Server (RS) * >> >> >> Definition: server that provides operations on >> /protected /resources; such operations require that the >> client provides valid access tokens issued by an AS >> >> >> A RS may offer both public resources and protected >> resources. Valid access tokens are only needed for >> protected resources. >> I propose the following definition while merging the >> two sentences: >> >> >> >> *Resource Server (RS) * >>       server that provides operations on resources >> /where/ protected operations require that the client >> provides /one or more/ valid access tokens issued by >> /one or more ASs/ >> >> >> In theabove modification I added "/one or more /". I am >> presuming that GNAP will allow the presentation of more >> that one access token from different ASs >> in order to allow an end-user to perform one operation >> on a protected resource. >> >> _5) Definition of Resource Owner_ _ >> _ >> The current definition is: >> >> >> *Resource Owner (RO) * >>      Definition: personal or organizational entity that >> may grant privileges on resources it has authority upon >> Note: the act of granting privileges may be manual >> (i.e. through an interaction) or automatic (i.e. >> through predefined rules). >> >> I don't know what a "personal entity" is but I know >> what a "natural person" is. >> >> Furthermore, a Resource Owner is not granting >> privileges (or access privileges) in the same way an AS >> is doing. >> >> It is interesting to take a look at ISO >> 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is >> defined as: >> >>       responsible party for the Resource(s) >>       Note 1 to entry: The Resource Owner is >> responsible for granting, denying, and revoking Access >> to Resource(s). >>       Note 2 to entry: The responsible Resource Owner >> is determined by the concrete Resource. >> >> >> I propose: >> >> >> *Resource Owner (RO) * >> /natural person /or organizational 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) or automatic >> (i.e. through predefined rules). >> __ >> >> >> _ >> 6) Definition of Access Token__ >> _ >> >> >> The current definition is: >> >> >> Access token >>      Definition: digitally signed data that contains >> specific rights and/or attributes >> Note 1: the access token can be issued to an end-user >> (usually requiring his authentication) and subsequently >> refreshed. >> The AS usually provides a method for the RO to revoke >> the privileges at any point in time. >>     Note 2: an access token may act as a capability >> (i.e. bearer token) or require an additional >> authentication by binding to a key (i.e. bound token) >> >> >> The definition is fine, but not the two Notes. >> >> >> The second sentence from the Note 1 is stating: "The AS >> usually provides a method for the RO to revoke the >> privileges at any point in time". >> Revoking "the privileges" is different from revoking an >> "access token". The second sentence of this Note 1 >> which is supposed to be about access token is confusing. >> The privileges may be changed at any point in time >> using a management function. Access tokens can be >> short-lived and thus don't need to be revoked. >> Any call-back from a RS to an AS should be avoided in >> order to respect the user's privacy. >> >> Therefore, I propose to remove the second part of this >> Note 1 and to replace "the" by "a" at the beginning of >> the first sentence. >> Note 2 is stating: >> Note 2: an access token may act as a capability (i.e. >> bearer token) or require an additional authentication >> by binding to a key (i.e. bound token) >> >> >> From the discussion on the list, I believe that we >> don't consider bearer tokens. Note 2 should be removed. >> >> >> So my proposal is as follows: >> >> >> *Access token * >>      digitally signed data that contains specific >> rights and/or attributes >> Note: an access token can be issued to an end-user >> (usually requiring his authentication) and subsequently >> refreshed. >> __ >> >> >> _ >> 7) Definition of Grant__ >> _ >> >> >> The current definition is: >> >> >> *Grant * >>      Definition: (verb): to permit, as a privilege >> given to an end-user to exercise some rights and/or >> assert attributes during a specific duration >> Definition: (noun): the act of granting >> >> The words ", as a privilege given to" are unnecessary" >> >> >> I propose: >> >> >> Grant >>      (verb): to permit an end-user to exercise some >> rights and/or /to/ assert /some /attributes /at a >> specific time and /during a specific duration >> (noun): the act of granting >> >> >> _8) Definition of Resource_ _ >> _ >> >> >> The current definition is: >> >> >> *Resource * >>       Definition: protected API served by a RS and >> accessed by a client, if and only if a valid access >> token is provided >> >> >> This definition is incorrect. This definition would be >> fine for a Protected Resource. Change it into >> "Protected Resource": >> >> >> *Protected Resource * >>      protected API served by a RS and /that can be >> /accessed by a client, if and only if a valid access >> token is provided >> >> >> If a definition of a Resource is needed, I propose: >> >> >> *Resource ** >> ***public or protected resource from a RS >> >> >> _ >> 9) Definition of Subject Information >> _ >> The current definition is: >> >> *Subject Information* >> Definition: claim asserted locally by an AS about a >> person, organization or device >> Source: >> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >> >> (unless we plan to use something specific to GNAP) >> >> This is information returned by an AS about an end-user. >> >> >> I would thus simply propose instead: >> * >> **     Subject Information * >>      information returned to a Client by an AS about an >> end-user >> >> Denis >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --------------FA58FC0B0185146919EC1FC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi Justin,

    I read your explanations several times and I must admit that I fail to grasp your point of view.

    From my point of view, there are two kinds of information that can be sent back by an AS to a Client:
    1.    an access token that contains in particular a subset of the claims about an end-user (among other data), or
    2.    information about the end-user.
    Let us focus on the second case. The AS holds personal information about the end-user but this does not means that all that information
    can/will become a claim that will be included into an access token. In particular, the end-user information may contain data that will never
    be included into an access token. As a conclusion, the claims about an end-user are a subset of the end-user information.

    In other words, a “claim” is NOT any statement made by an potentially authoritative source, the AS.

    In Europe, we now have in force the GDPR (General Data Protection Regulation), i.e. the REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT
    AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement
    of such data, and repealing Directive 95/46/EC.

    It is available in 24 languages here:  https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679

    Article 15 which is about the "Right of access by the data subject" states:

    1. The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him
    or her are being processed, and, where that is the case, access to the personal data and the following information:
    (a)    the purposes of the processing;
    (b)    the categories of personal data concerned;
    (...)
    Let us use an example to illustrate this. Some banks require to know the marital name of the mother of the end-user or/and her first name.
    It is an information that the end-user knows and will not forget. Such marital name is not intended to be included into an access token.
    It is used to authenticate the end-user when he/she is making a phone call to the bank. If such information has been collected, the marital name
    of the mother of the end-user may be returned in the "information about the end-user".

    The information retuned by an AS to a Client about the end-user should include at least:
    (a) the categories of personal data concerned,
    (b) the personal data and
    (c) the purposes of the processing (e.g. may be included as a claim into an access token).
    So I believe that my proposal is still adequate:
    end-user information: information returned to a Client by an AS about an end-user
    In the core of the document, we may provide more explanations.

    Denis

    Yes that's useful. In that case we're closer to the definition that we have in my previous email, than to that proposed by Denis. 

    Le ven. 18 déc. 2020 à 18:42, Justin Richer <jricher@mit.edu> a écrit :
    There’s a subtlety about “subject information” that I think we need to be careful not to lose, in that it’s the intersection of two different aspects of data rights being given to the client. I’m not sure how best to frame this, so apologies if this sprawls a bit:

    First, there’s the dimension of how the data is transmitted to the client. This is a fundamental difference between rights associated with an access token and data being sent back directly to the client in a response message from the AS. The access token is handled by the “resources” request (pending proposed restructure/rename, but that’s the current spec). This tells the AS the things the token can do, but as we all know a big part of that in practice is about what data the token can be used for, and therefore what data the client has access to. The other information is what’s sent directly to the client, and it’s somewhat “new” for GNAP. OpenID Connect showed us the value of passing back an assertion directly to the client, and GNAP is making this kind of “Direct returned information” a first-class citizen, to the point that mechanisms for returning this is in our charter. This could be wrapped in an assertion or returned as raw data, and GNAP currently allows both.

    The second dimension is what the data is about, regardless of how it gets back. There are lots of ways to look at this, but one fundamental question is whether the data is :about: the end user or not. Identity is far from the only use case for GNAP, but we know that it’s going to be a driving one for many developers. And when you’re talking about identity information, the distinction between the RQ and RO really comes into sharp relief: are you asking about the current user, or about some other user on a different system, and are they the same person?

    So in total it’s something like this:

                       |     Delivery Method       |
                       |                           |
                       | Direct      |  Resource   |
    -----------------------------------------------+
              End User | Subject     |  UserInfo   |
        Data           | Information |  Endpoint   |
     Subject  -------------------------------------+
                Other  | ???         |  Resource   |
                       |             |  Server API |
    -----------------------------------------------+

    Is this a useful diagram and distinction to make in our discussion?

    Also for what it’s worth, the OpenID Connect “claims” language would cover everything in that square. It’s primarily about the end user, but doesn’t have to be as the OIDC spec itself stats that it provides methods for "Claims about the End-User and the Authentication event”. In other words, a “claim” is any statement made by an potentially authoritative source, the AS.

     — Justin

    On Dec 18, 2020, at 12:02 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Thanks Denis, that's a really useful feedback. I'll review that in more detail, but something that's really not clear to me is the last one, subject information.

    1) is it about the end-user ? or the RO ? (as is the current definition in V02)
    2) why do we even need to call it subject information ? For instance if it's about the end-user, it should only be end-user information. 
    3) do we want to use entity or subject in the definitions ? (cf RO for instance). Regarding natural person vs entity we had a discussion on the mailing list previously. 

    Cheers,
    Fabien

    On Fri, Dec 18, 2020 at 5:47 PM Denis <denis.ietf@free.fr> wrote:

    FYI, the wiki page is there:  https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ideas and you will notice that a given term may be used in different ISO standards with a different definition.  

    I have nine comments (each one being numbered).

    1) Current definition of AS    :  

    The current definition is:

         Authorization Server (AS)
         Definition: server that grants privileges to a particular end-user and that provides them to a client in the form of an access token

    This is fine in general (but see later another comment about it), but the word privileges is left undefined.  

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page: "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synonym of a permission.      

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

         privilege  
        access right
        permission
        authorization to a subject (3.15) to access a resource (3.14)

            Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request is granted according to its access control policy.
                                  The access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

            Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
                                  that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

            privilege: right or attribute associated with an end-user

    with:
            right: ability given to an end-user to perform a given operation on an object under the control of a RS

              attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

         Client
         Definition: application that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

         Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
                  (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
            Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
     
              Client: application used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

     
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "access privileges".
    The words "a negotiation of" should be deleted.

    This raises the point where this definition of a "Client" is using the wording     "access privileges" whereas the definition of an "Authorization Server (AS)"
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could also live with "privileges".  

    Hence my proposals:

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

        Authorization Server (AS)
         server that grants access privileges to a particular end-user and that provides them to a client in the form of an access token
     
    4) Definition of a Resource Server (RS)

    The current definition is:

         Resource Server (RS)

         Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


          Resource Server (RS)
          server that provides operations on resources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the  above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
     
    5) Definition of Resource Owner  

    The current definition is:

         Resource Owner (RO)
         Definition: personal or organizational entity that may grant privileges on resources it has authority upon
            Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural person" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

          responsible party for the Resource(s)
          Note 1 to entry: The Resource Owner is responsible for granting, denying, and revoking Access to Resource(s).
          Note 2 to entry: The responsible Resource Owner is determined by the concrete Resource.

    I propose:

         Resource Owner (RO)
         natural person or organizational 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) or automatic (i.e. through predefined rules).


    6) Definition of Access Token      

    The current definition is:

         Access token
         Definition: digitally signed data that contains specific rights and/or attributes
            Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
                    The AS usually provides a method for the RO to revoke the privileges at any point in time.         
        Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from the Note 1 is stating: "The AS usually provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an "access token". The second sentence of this Note 1 which is supposed to be about access token is confusing.
    The privileges may be changed at any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sentence.
    Note 2 is stating:
              Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as follows:

         Access token
         digitally signed data that contains specific rights and/or attributes   
            Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant      

    The current definition is:

         Grant
         Definition: (verb): to permit, as a privilege given to an end-user to exercise some rights and/or assert attributes during a specific duration
            Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

         Grant
         (verb): to permit an end-user to exercise some rights and/or to assert some attributes at a specific time and during a specific duration
            (noun): the act of granting
     
     
    8) Definition of Resource  

    The current definition is:

         Resource
          Definition: protected API served by a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

         Protected Resource
         protected API served by a RS and that can be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

         Resource
         public or protected resource from a RS


    9) Definition of Subject Information

    The current definition is:
     
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propose instead:

         Subject Information
         information returned to a Client by an AS about an end-user
     
    Denis


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


    --------------FA58FC0B0185146919EC1FC6-- From nobody Mon Dec 21 03:45:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0546D3A1050 for ; Mon, 21 Dec 2020 03:45:42 -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 Fy017vYMcHto for ; Mon, 21 Dec 2020 03:45:38 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0E63A104D for ; Mon, 21 Dec 2020 03:45:38 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id g1so8605426ilk.7 for ; Mon, 21 Dec 2020 03:45: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=yOmc9SuRcueXr+xU6bJJ5m4kdQgmNwP2J5UhnZYa4lo=; b=KrY8xDq5WP5XVKtPx8I0RbAxAEAUMYG1XrV9p6tCedcsvCBOrMi22RzEqAL9PufP8o TjXF8BcE2rP1JjXX3iNC3GhCgkY6UNrx8s7LT8c4BpUrhTae696/X7QE1XEZEHXnaWnV FHv4pvnVvrZW/JCra9YlTgQvNbj5OwyRpQLNIx6H+CuOLjKAPZImCaISs85AH4+cj6z0 CUvozfQyXjjpfj0QAAj95BSFXe4ojUnlxnFzio1yqveabXBzmsyIU3oHVVeh12njKzZ7 gijmhNn4CVFwhZGk48dm5X5BeaVEoq6W7HtGNwS0ORb28KApCRHo9LC9N6/kvIvhPQo8 do3w== 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=yOmc9SuRcueXr+xU6bJJ5m4kdQgmNwP2J5UhnZYa4lo=; b=kK3Og+8I0Gd4d12gcEzBz2WJa1gDNeZxvrxuJQ76emBFIOeuThwVqGTGQv/urBaDnd VJQEY+ajll6Dar2ywrvooUxH25f3UVkQ2Mb3giF/9NIexAsscXU/hkdYqkB/5F06m/yP N2v+6Kc2zFQFfrnj4IToTlQevEuRZkZtslP3g60xBmLGG0Qzb80m/hegIVvwav4a5glk ZUtFm80bXv35xo322u2awoLazQDp/rqet+BX308FkPw7LCAoKtzKiQkpT4BnhuDI9F0N FgOeXzaE6CmLb6xeM6qJBaxvXlWIKzohGsLKko98V8gqDFV5hggvlKD/7EOjg++AayO8 ffOw== X-Gm-Message-State: AOAM533PbQAe/UN4Vqy6tcqdIyEgoFb7CVrPLqIgTIr5M0HyOd5NeZ67 f8gi9MesinHUySodJ1Wq1m6IKF6pgtZ6pFQUsAE= X-Google-Smtp-Source: ABdhPJwo2TFY1hce+v2yisEpquYmMA9p9kujBt3J4hg/cvF9Lydgyzi/N9kBaIJ6ZOx0qexPUDTcKTWq9ecVtyIbYfo= X-Received: by 2002:a92:d34c:: with SMTP id a12mr16067935ilh.188.1608551137504; Mon, 21 Dec 2020 03:45:37 -0800 (PST) MIME-Version: 1.0 References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> <0E0E3DD6-24E0-47BE-8441-9426C1FB7AEE@mit.edu> <8d493c75-0970-1df8-dab2-29b78bba06a6@free.fr> In-Reply-To: <8d493c75-0970-1df8-dab2-29b78bba06a6@free.fr> From: Fabien Imbault Date: Mon, 21 Dec 2020 12:45:24 +0100 Message-ID: To: Denis Cc: Justin Richer , txauth gnap Content-Type: multipart/alternative; boundary="00000000000027740305b6f7ffaa" Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 21 Dec 2020 11:45:42 -0000 --00000000000027740305b6f7ffaa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Denis, Isn't defining "end-user (or subject) information" by something that starts with information a bit circular? If we use "claim =3D statement about a subject", we avoid that issue and still focus on the part of the information that needs to transit between the AS and the client. What's important is not so much that it is a subset of the full information, but that it is delivered under some authority, here the AS. The remaining question is whether that statement can also be about other subjects than the end-user alone. That's how I understood Justin's comment, and unless we're 100% sure we'll never need anything else than end-user information, I'd suggest we keep that open for the time being. Fabien On Mon, Dec 21, 2020 at 12:13 PM Denis wrote: > Hi Justin, > > I read your explanations several times and I must admit that I fail to > grasp your point of view. > > From my point of view, there are two kinds of information that can be sen= t > back by an AS to a Client: > > 1. an access token that contains in particular a subset of the > claims about an end-user (among other data), or > 2. information about the end-user. > > Let us focus on the second case. The AS holds personal information about > the end-user but this does not means that all that information > can/will become a claim that will be included into an access token. In > particular, the end-user information may contain data that will never > be included into an access token. As a conclusion, the claims about an > end-user are a subset of the end-user information. > > In other words, a =E2=80=9Cclaim=E2=80=9D is NOT any statement made by an= potentially > authoritative source, the AS. > > In Europe, we now have in force the GDPR (General Data Protection > Regulation), i.e. the REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT > AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons > with regard to the processing of personal data and on the free movement > of such data, and repealing Directive 95/46/EC. > > It is available in 24 languages here: > https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=3DCELEX%3A32016R0679 > > Article 15 which is about the "Right of access by the data subject" state= s: > > 1. The data subject shall have the right to obtain from the controller > confirmation as to whether or not personal data concerning him > or her are being processed, and, where that is the case, access to the > personal data and the following information: > > (a) the purposes of the processing; > (b) the categories of personal data concerned; > (...) > > Let us use an example to illustrate this. Some banks require to know the > marital name of the mother of the end-user or/and her first name. > It is an information that the end-user knows and will not forget. Such > marital name is not intended to be included into an access token. > It is used to authenticate the end-user when he/she is making a phone cal= l > to the bank. If such information has been collected, the marital name > of the mother of the end-user may be returned in the "information about > the end-user". > > The information retuned by an AS to a Client about the end-user should > include at least: > > (a) the categories of personal data concerned, > (b) the personal data and > (c) the purposes of the processing (e.g. may be included as a claim into > an access token). > > So I believe that my proposal is still adequate: > > end-user information: information returned to a Client by an AS about an > end-user > > In the core of the document, we may provide more explanations. > > Denis > > Yes that's useful. In that case we're closer to the definition that we > have in my previous email, than to that proposed by Denis. > > Le ven. 18 d=C3=A9c. 2020 =C3=A0 18:42, Justin Richer a= =C3=A9crit : > >> There=E2=80=99s a subtlety about =E2=80=9Csubject information=E2=80=9D t= hat I think we need to be >> careful not to lose, in that it=E2=80=99s the intersection of two differ= ent aspects >> of data rights being given to the client. I=E2=80=99m not sure how best = to frame >> this, so apologies if this sprawls a bit: >> >> First, there=E2=80=99s the dimension of how the data is transmitted to t= he >> client. This is a fundamental difference between rights associated with = an >> access token and data being sent back directly to the client in a respon= se >> message from the AS. The access token is handled by the =E2=80=9Cresourc= es=E2=80=9D request >> (pending proposed restructure/rename, but that=E2=80=99s the current spe= c). This >> tells the AS the things the token can do, but as we all know a big part = of >> that in practice is about what data the token can be used for, and >> therefore what data the client has access to. The other information is >> what=E2=80=99s sent directly to the client, and it=E2=80=99s somewhat = =E2=80=9Cnew=E2=80=9D for GNAP. >> OpenID Connect showed us the value of passing back an assertion directly= to >> the client, and GNAP is making this kind of =E2=80=9CDirect returned inf= ormation=E2=80=9D a >> first-class citizen, to the point that mechanisms for returning this is = in >> our charter. This could be wrapped in an assertion or returned as raw da= ta, >> and GNAP currently allows both. >> >> The second dimension is what the data is about, regardless of how it get= s >> back. There are lots of ways to look at this, but one fundamental questi= on >> is whether the data is :about: the end user or not. Identity is far from >> the only use case for GNAP, but we know that it=E2=80=99s going to be a = driving one >> for many developers. And when you=E2=80=99re talking about identity info= rmation, >> the distinction between the RQ and RO really comes into sharp relief: ar= e >> you asking about the current user, or about some other user on a differe= nt >> system, and are they the same person? >> >> So in total it=E2=80=99s something like this: >> >> | Delivery Method | >> | | >> | Direct | Resource | >> -----------------------------------------------+ >> End User | Subject | UserInfo | >> Data | Information | Endpoint | >> Subject -------------------------------------+ >> Other | ??? | Resource | >> | | Server API | >> -----------------------------------------------+ >> >> Is this a useful diagram and distinction to make in our discussion? >> >> Also for what it=E2=80=99s worth, the OpenID Connect =E2=80=9Cclaims=E2= =80=9D language would >> cover everything in that square. It=E2=80=99s primarily about the end us= er, but >> doesn=E2=80=99t have to be as the OIDC spec itself stats that it provide= s methods >> for "Claims about the End-User and the Authentication event=E2=80=9D. In= other >> words, a =E2=80=9Cclaim=E2=80=9D is any statement made by an potentially= authoritative >> source, the AS. >> >> =E2=80=94 Justin >> >> On Dec 18, 2020, at 12:02 PM, Fabien Imbault >> wrote: >> >> Thanks Denis, that's a really useful feedback. I'll review that in more >> detail, but something that's really not clear to me is the last one, >> subject information. >> >> 1) is it about the end-user ? or the RO ? (as is the current definition >> in V02) >> 2) why do we even need to call it subject information ? For instance if >> it's about the end-user, it should only be end-user information. >> 3) do we want to use entity or subject in the definitions ? (cf RO for >> instance). Regarding natural person vs entity we had a discussion on the >> mailing list previously. >> >> Cheers, >> Fabien >> >> On Fri, Dec 18, 2020 at 5:47 PM Denis wrote: >> >>> >>> FYI, the wiki page is there: >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >>> FYI first, there is a useful web page where you can find all the ISO >>> definitions as well as the text for any ISO standard (up to its definit= ion >>> section only): >>> https://www.iso.org/obp >>> This may provide some ideas and you will notice that a given term may b= e >>> used in different ISO standards with a different definition. >>> >>> I have nine comments (each one being numbered). >>> >>> * 1) Current definition of AS*: >>> >>> The current definition is: >>> >>> *Authorization Server (AS) * >>> Definition: server that grants privileges to a particular end-user >>> and that provides them to a client in the form of an access token >>> This is fine in general (but see later another comment about it), but >>> the word privileges is left undefined. >>> >>> * 2) Definition of a privilege* >>> A suggested "privilege" definition has been proposed in the wiki page: = "A >>> privilege is the right to perform an operation (or action) on a Resourc= e." >>> See also other def >>> >>> . >>> In the "other def.", the term is considered to be a synonym of a >>> permission. >>> >>> ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following : >>> >>> privilege >>> access right >>> permission >>> authorization to a subject (3.15) >>> to access a resource (3.14) >>> >>> >>> Note 1 to entry: Privilege is a necessary but not sufficient >>> condition for access. Access occurs when the access request is granted >>> according to its access control policy. >>> The access control policy is based on >>> privileges and may include other environmental factors (e.g. >>> time-of-day, location, etc.) >>> >>> Note 2 to entry: Privileges take the form of data presented by a >>> subject or obtained for a subject that is used by a Policy Decision Poi= nt >>> in order to grant or deny an operation >>> that a subject is willing to perform on a >>> resource. >>> (...) >>> I propose the following: >>> >>> *privilege*: right or attribute associated with an end-user >>> with: >>> *right*: ability given to an end-user to perform a given >>> operation on an object under the control of a RS >>> >>> *attribute*: characteristics or property related to an end-user >>> >>> >>> >>> *3) Definition of a Client * The current definition is: >>> *Client * >>> Definition: application that consumes resources from one or severa= l >>> RSs, possibly requiring a negotiation of access privileges with one or >>> several ASs >>> >>> Note: this specification differentiates between a specific instanc= e >>> (the client instance, identified by its public key) and the software >>> running the instance >>> (the client software). For some kinds of client software, >>> there could be many instances of a single piece of client software. >>> Example: a client can be a mobile application, a web application, >>> etc. >>> >>> Previously, I proposed: >>> >>> *Client*: application used by an end-user to interact with an AS >>> or a RS >>> >>> The current definition is missing to indicate who is operating the >>> client. It is an end-user, i.e. it is not another application, nor a >>> process, nor an entity. >>> The definition should capture this point. >>> A second point: the current definition is using the wording "requiring >>> a negotiation". There is no "negotiation". Either the AS has or has not >>> the "access privileges". >>> The words "a negotiation of" should be deleted. >>> >>> This raises the point where this definition of a "Client" is using the >>> wording "*access privileges*" whereas the definition of an >>> "Authorization Server (AS)" >>> is using the word "*privileges*". We should make both definitions >>> consistent. I have a slight preference for "access privileges", but I c= ould >>> also live with "privileges". >>> >>> Hence my proposals: >>> >>> * Client * >>> application *operated* *by an end-user *that consumes resources >>> from one or several RSs, possibly requiring *access privileges from* >>> one or several ASs >>> >>> * Authorization Server (AS) * >>> server that grants *access* privileges to a particular end-user >>> and that provides them to a client in the form of an access token >>> >>> >>> *4) Definition of a Resource Server (RS) * >>> The current definition is: >>> >>> * Resource Server (RS) * >>> Definition: server that provides operations on *protected *resourc= es; >>> such operations require that the client provides valid access tokens is= sued >>> by an AS >>> A RS may offer both public resources and protected resources. Valid >>> access tokens are only needed for protected resources. >>> I propose the following definition while merging the two sentences: >>> >>> *Resource Server (RS) * >>> server that provides operations on resources *where* protected >>> operations require that the client provides *one or more* valid access >>> tokens issued by *one or more ASs* >>> In the above modification I added "*one or more *". I am presuming >>> that GNAP will allow the presentation of more that one access token fro= m >>> different ASs >>> in order to allow an end-user to perform one operation on a protected >>> resource. >>> >>> *5) Definition of Resource Owner* >>> >>> The current definition is: >>> * Resource Owner (RO) * >>> Definition: personal or organizational entity that may grant >>> privileges on resources it has authority upon >>> Note: the act of granting privileges may be manual (i.e. through an >>> interaction) or automatic (i.e. through predefined rules). >>> >>> I don't know what a "personal entity" is but I know what a "natural >>> person" is. >>> >>> Furthermore, a Resource Owner is not granting privileges (or access >>> privileges) in the same way an AS is doing. >>> >>> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where >>> Resource Owner (RO) is defined as: >>> >>> responsible party for the Resource(s) >>> Note 1 to entry: The Resource Owner is responsible for granting, >>> denying, and revoking Access to Resource(s). >>> Note 2 to entry: The responsible Resource Owner is determined by >>> the concrete Resource. >>> I propose: >>> *Resource Owner (RO) * >>> *natural person *or organizational 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) or automatic (i.e. through predefined rul= es). >>> >>> * 6) Definition of Access Token* >>> The current definition is: >>> Access token >>> Definition: digitally signed data that contains specific rights >>> and/or attributes >>> Note 1: the access token can be issued to an end-user (usually >>> requiring his authentication) and subsequently refreshed. >>> The AS usually provides a method for the RO to revoke >>> the privileges at any point in time. >>> Note 2: an access token may act as a capability (i.e. bearer token) >>> or require an additional authentication by binding to a key (i.e. bound >>> token) >>> The definition is fine, but not the two Notes. >>> The second sentence from the Note 1 is stating: "The AS usually >>> provides a method for the RO to revoke the privileges at any point in t= ime". >>> Revoking "the privileges" is different from revoking an "access token". >>> The second sentence of this Note 1 which is supposed to be about access >>> token is confusing. >>> The privileges may be changed at any point in time using a management >>> function. Access tokens can be short-lived and thus don't need to be >>> revoked. >>> Any call-back from a RS to an AS should be avoided in order to respect >>> the user's privacy. >>> >>> Therefore, I propose to remove the second part of this Note 1 and to >>> replace "the" by "a" at the beginning of the first sentence. >>> Note 2 is stating: >>> Note 2: an access token may act as a capability (i.e. bearer >>> token) or require an additional authentication by binding to a key >>> (i.e. bound token) >>> From the discussion on the list, I believe that we don't consider beare= r >>> tokens. Note 2 should be removed. >>> So my proposal is as follows: >>> * Access token * >>> digitally signed data that contains specific rights and/or >>> attributes >>> Note: an access token can be issued to an end-user (usually >>> requiring his authentication) and subsequently refreshed. >>> >>> * 7) Definition of Grant* >>> The current definition is: >>> * Grant * >>> Definition: (verb): to permit, as a privilege given to an end-user >>> to exercise some rights and/or assert attributes during a specific >>> duration >>> Definition: (noun): the act of granting >>> >>> The words ", as a privilege given to" are unnecessary" >>> I propose: >>> Grant >>> (verb): to permit an end-user to exercise some rights and/or *to* >>> assert *some *attributes *at a specific time and *during a specific >>> duration >>> (noun): the act of granting >>> >>> >>> *8) Definition of Resource* >>> The current definition is: >>> * Resource * >>> Definition: protected API served by a RS and accessed by a client= , >>> if and only if a valid access token is provided >>> This definition is incorrect. This definition would be fine for a >>> Protected Resource. Change it into "Protected Resource": >>> * Protected Resource * >>> protected API served by a RS and *that can be *accessed by a >>> client, if and only if a valid access token is provided >>> If a definition of a Resource is needed, I propose: >>> * Resource * >>> public or protected resource from a RS >>> >>> * 9) Definition of Subject Information * >>> The current definition is: >>> >>> *Subject Information* >>> Definition: claim asserted locally by an AS about a person, >>> organization or device >>> Source: >>> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >>> (unless we plan to use something specific to GNAP) >>> >>> This is information returned by an AS about an end-user. >>> I would thus simply propose instead: >>> >>> * Subject Information * >>> information returned to a Client by an AS about an end-user >>> >>> Denis >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> > --00000000000027740305b6f7ffaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Denis,=C2=A0

    Isn't defining &quo= t;end-user (or subject) information" by something that starts with inf= ormation a bit circular?

    If we use "claim =3D= statement about a subject", we avoid that issue and still focus on th= e part of the information that needs to transit between the AS and the clie= nt. What's important is not so much that it is a subset of the full inf= ormation, but that it is delivered under some authority, here the AS.
    =

    The remaining question is whether that statement can al= so be about other subjects than the end-user alone. That's how I unders= tood Justin's comment, and unless we're 100% sure we'll never n= eed anything else than end-user information, I'd suggest we keep that o= pen for the time being.

    Fabien


    On Mon, Dec 21, 2020 at 12:13 PM Denis <denis.ietf@free.fr> wrote:
    =20 =20 =20
    Hi Justin,

    I read your explanations several times and I must admit that I fail to grasp your point of view.

    From my point of view, there are two kinds of information that can be sent back by an AS to a Client:
    1. =C2=A0=C2=A0 an access token that contains in particular a subs= et of the claims about an end-user (among other data), or
    2. =C2=A0=C2=A0 information about the end-user.
    Let us focus on the second case. The AS holds personal information about the end-user but this does not means that all that information
    can/will become a claim that will be included into an access token. In particular, the end-user information may contain data that will never
    be included into an access token. As a conclusion, the claims about an end-user are a subset of the end-user information.

    In other words, a =E2=80=9Cclaim=E2=80=9D is NOT any statement made b= y an potentially authoritative source, the AS.

    In Europe, we now have in force the GDPR (General Data Protection Regulation), i.e. the REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT
    AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement
    of such data, and repealing Directive 95/46/EC.

    It is available in 24 languages here:=C2=A0 <= a href=3D"https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=3DCELEX%3A320= 16R0679" target=3D"_blank">https://eur-lex.europa.eu/legal-content/EN/TXT/?= uri=3DCELEX%3A32016R0679

    Article 15 which is about the "Right of access by the data subject" states:

    1. The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him
    or her are being processed, and, where that is the case, access to the personal data and the following information:
    (a)=C2=A0=C2=A0=C2=A0 the purposes of the processing; (b)=C2=A0=C2=A0=C2=A0 the categories of personal data concerned; (...)
    Let us use an example to illustrate this. Some banks require to know the marital name of the mother of the end-user or/and her first name.
    It is an information that the end-user knows and will not forget. Such marital name is not intended to be included into an access token.
    It is used to authenticate the end-user when he/she is making a phone call to the bank. If such information has been collected, the marital name
    of the mother of the end-user may be returned in the "informatio= n about the end-user".

    The information retuned by an AS to a Client about the end-user should include at least:
    (a) the categories of personal data concerned,
    (b) the personal data and
    (c) the purposes of the processing (e.g. may be included as a claim into an access token).
    So I believe that my proposal is still adequate:
    end-user information: information returned to a Client by an AS about an end-user
    In the core of the document, we may provide more explanations.

    Denis

    =20
    Yes that's useful. In that case we're close= r to the definition that we have in my previous email, than to that proposed by Denis.=C2=A0

    Le ven. 18 d=C3=A9c. 2020 =C3= =A0 18:42, Justin Richer <jricher@mit.edu> a =C3=A9crit=C2=A0:
    There=E2=80=99s a subtlety about =E2=80=9Csubject information=E2=80=9D that I t= hink we need to be careful not to lose, in that it=E2=80=99s the intersectio= n of two different aspects of data rights being given to the client. I=E2=80=99m not sure how best to frame this, so apologi= es if this sprawls a bit:

    First, there=E2=80=99s the dimension of how the data is transmitted to the client. This is a fundamental difference between rights associated with an access token and data being sent back directly to the client in a response message from the AS. The access token is handled by the =E2=80=9Cresources=E2=80=9D request (pending proposed restructure/rename, but that=E2=80=99s the current spec). Thi= s tells the AS the things the token can do, but as we all know a big part of that in practice is about what data the token can be used for, and therefore what data the client has access to. The other information is what=E2=80=99s sent directly to the client, and it=E2=80=99s somewhat =E2=80=9Cne= w=E2=80=9D for GNAP. OpenID Connect showed us the value of passing back an assertion directly to the client, and GNAP is making this kind of =E2=80=9CDirect returned information=E2=80=9D a first= -class citizen, to the point that mechanisms for returning this is in our charter. This could be wrapped in an assertion or returned as raw data, and GNAP currently allows both.

    The second dimension is what the data is about, regardless of how it gets back. There are lots of ways to look at this, but one fundamental question is whether the data is :about: the end user or not. Identity is far from the only use case for GNAP, but we know that it=E2=80=99s goi= ng to be a driving one for many developers. And when you=E2=80=99re talking about identity information, the distinction between the RQ and RO really comes into sharp relief: are you asking about the current user, or about some other user on a different system, and are they the same person?

    So in total it=E2=80=99s something like this:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 Delivery Method =C2=A0 =C2=A0 =C2=A0 |
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Direct =C2=A0 =C2=A0 =C2=A0| =C2=A0Resource =C2=A0 |
    -----------------------------= ------------------+
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 End User | Subject =C2=A0 =C2=A0 | =C2=A0UserInfo =C2=A0 |
    =C2=A0 =C2=A0 Data =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | Information | =C2=A0Endpoint =C2=A0 |
    =C2=A0Subject =C2=A0-------------------------------------+
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Other =C2=A0| ??? =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Resource =C2=A0 |
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0Server API |
    -----------------------------= ------------------+

    Is this a useful diagram and distinction to make in our discussion?

    Also for what it=E2=80=99s worth, the OpenID Connect =E2= =80=9Cclaims=E2=80=9D language would cover everything in that square. It=E2=80=99s primarily about the end user, but doesn=E2=80=99t have to be = as the OIDC spec itself stats that it provides methods for "Claims about the End-User and the Authentication event= =E2=80=9D. In other words, a =E2=80=9Cclaim=E2=80=9D is any statement ma= de by an potentially authoritative source, the AS.

    =C2=A0=E2=80=94 Justin

    On Dec 18, 2020, at 12:02 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Thanks Denis, that's a really useful feedback. I'll review that in more detail, but something that's really not clear to me is the last one, subject information.

    1) is it about the end-user ? or the RO ? (as is the current definition in V02)
    2) why do we even need to call it subject information ? For instance if it's about th= e end-user, it should only be end-user information.=C2=A0
    3) do we want to use entity or subject in the definitions ? (cf RO for instance). Regarding natural person vs entity we had a discussion on the mailing list previously.=C2= =A0

    Cheers,
    Fabien

    On Fri, Dec 18, 2020 at 5:47 PM Denis <denis.ietf@free.f= r> wrote:

    FYI, the wiki page is there:=C2=A0 https://github.com/ietf-= wg-gnap/gnap-core-protocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https= ://www.iso.org/obp

    This may provide some ideas and you will notice that a given term may be used in different ISO standards with a different definition. =C2=A0=

    I have nine comments (each one being numbered).

    1) Current definition of AS    : = =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Authorization Server (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition= : server that grants privileges to a particular end-user and that provides them to a client in the form of an access token

    This is fine in general (but see later another comment about it), but the word pr= ivileges is left undefined. =C2=A0
    2) Definition of a privilege    =

    A suggested "privilege" definitio= n has been proposed in the wiki page: "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term i= s considered to be a synonym of a permission.     =C2=A0

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

    =C2=A0=C2=A0= =C2=A0=C2=A0 privilege =C2=A0
    =C2=A0=C2=A0=C2=A0 access right
    =C2=A0=C2=A0=C2=A0 permission
    =C2=A0=C2=A0=C2=A0 authorization to= a subject (3.15) to access a resource (3.14)

    =C2=A0=C2=A0=C2=A0     N= ote 1 to entry: Privilege is a nece= ssary but not sufficient condition for access. Access occurs when= the access request is granted according to its access control policy.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0 The access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

    =C2=A0=C2=A0=C2=A0     N= ote 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 privilege: right or attribute associated with an end-user

    with:
    =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 = right: ability given to an end-user to perform a given operation on an object under the control of a RS

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

    =C2=A0= =C2=A0=C2=A0=C2=A0 Client
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: appl= ication that consumes resources from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

    =C2=A0=C2=A0=C2=A0=C2=A0 Note: this speci= fication differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
    =C2=A0=C2=A0=C2=A0 Example= : a client can be a mobile application, a web application, etc.

    Previously, I proposed:
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Client: application used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

    =C2=A0
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS ha= s or has not the "access privileges"= .
    The words "a negotiation of" should be deleted.

    This raises the point where this definition of a "Client" is usi= ng the wording     "access pr= ivileges" whereas the definition of an "Authorization Server (AS)" is using the word "privileges= ". We should make both definitions consistent. I have a slight preference for "access privileges", but I = could also live with "privileges". =C2=A0

    Hence my proposals:

    =C2=A0=C2=A0=C2=A0=C2=A0 Client =C2=A0=C2=A0=C2=A0=C2=A0 application o= perated by an end-user that con= sumes resources from one or several RSs, possibly requiring access privileges from one or several ASs

    =C2=A0=C2=A0=C2=A0 Authorization S= erver (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 server that gran= ts access privileges to a particular end-user and that provides them to a client in the form of an access token
    =C2=A0
    4) Definition of a Resource Server (RS)

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource = Server (RS)

    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resourc= e Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server tha= t provides operations on resources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the=C2=A0 above modification I added "one or more ". = I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
    =C2=A0
    5) Definition of Resource Owner =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: pers= onal or organizational entity that may grant privileges     on resources it has authority upon=
    =C2=A0=C2=A0=C2=A0     Note: t= he act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal en= tity" is but I know what a "natural person= " is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsibl= e party for the Resource(s)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 1 to = entry: The Resource Owner is responsible for granting, denying, and revoking Access to Resource(s).
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 2 to = entry: The responsible Resource Owner is determined by the concrete Resource.

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 natural perso= n or organizational entity that may grant or deny operations on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: t= he act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).


    6) Definition of Access Token =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: digi= tally signed data that contains specific rights and/or attributes
    =C2=A0=C2=A0=C2=A0     Note 1:= the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The AS usually provides a method for the RO to revoke the privileges at any point in time.    = =C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Note 2: an access toke= n may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from the Note 1 is stating: "The AS usually provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is di= fferent from revoking an "access token"= . The second sentence of this Note 1 which is supposed to be about access token is confusing.
    The privileges may be changed at any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" = at the beginning of the first sentence.
    Note 2 is stating:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as follows:

    =C2=A0=C2=A0=C2=A0=C2=A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 digitally signed= data that contains specific rights and/or attributes =C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0     Note: a= n access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: (ver= b): to permit, as a privilege given to an end-user to exercise some rights and/or assert attributes during a specific duration
    =C2=A0=C2=A0=C2=A0     Definit= ion: (noun): the act of granting

    The words ", as a privilege given to= " are unnecessary"

    I propose:

    =C2=A0= =C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 (verb): to permi= t an end-user to exercis= e some rights and/or to assert some attributes at a specific time and during a specific duration
    =C2=A0=C2=A0=C2=A0     (noun):= the act of granting
    =C2=A0
    =C2=A0
    8) Definition of Resource = =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definition= : protected API served by a RS and accessed by a client, if and only if a valid access token is provided    <= span style=3D"font-family:Arial;font-weight:normal" lang=3D"EN-US">

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

    =C2=A0=C2=A0=C2=A0=C2=A0 Protected Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 protected API se= rved by a RS and that can be accessed by a client, if and only if a valid access token is provided    <= span style=3D"font-family:Arial;font-weight:normal" lang=3D"EN-US">

    If a definition of a Resource is needed, I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 publi= c or protected resource from a RS


    9) Definition of Subject Information

    The current definition is:
    =C2=A0
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.org/html/draft-ietf-secevent-su= bject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propose instead:

    =C2=A0=C2=A0=C2=A0=C2=A0 Subject I= nformation
    =C2=A0=C2=A0=C2=A0=C2=A0 information retu= rned to a Client by an AS about an end-user
    =C2=A0
    Denis


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


    --00000000000027740305b6f7ffaa-- From nobody Mon Dec 21 09:06:33 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D503A1248 for ; Mon, 21 Dec 2020 09:06: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 UPgnq07vWbB1 for ; Mon, 21 Dec 2020 09:06:27 -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 1BF0E3A1244 for ; Mon, 21 Dec 2020 09:06:27 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id j12so9414796ota.7 for ; Mon, 21 Dec 2020 09:06:26 -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=nFBW1Vk4DqIqv9YYzV1PmfXvz+si3tMUpcFvlmzlq9c=; b=s0CpG9bP1zqp9RXVV9KQR+qi8l+SiQrFRK6kZXQKMDw0Y2zuNjTIzC9oiu7FJ3C5dR RAfwimPXSMwIrYenX0RPQVjfRxJ72c0Ok4odwPd45/N0DqCqpaiusz4oRjdxJkmr3Ths KwzimyBcYqflzdZkRi6v+iZPbzKINPQXunz0w8vG7mGffyx66ggWl3FZbRq4LwbTiI16 DeJJWssJ0SlpezAJ9oWppw6LCtTe6ulXpCP/V7NjtrPsV4x0cNfbMQTabOOtqDfCjajz cYjmpSsHQK99uYvafGr5QbPcs2Ps1l+9uQST+xvHIv2FkKK/UMVMY3kDwFl6XMFKzLE1 Q0xA== 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=nFBW1Vk4DqIqv9YYzV1PmfXvz+si3tMUpcFvlmzlq9c=; b=qoke1e/KwO1JIdK990jltellvOyOXbyILYkInQg5A//Dkqw/acX1xt0UdG75E4VPq9 d9zQPPacB74Cc7laWtAugeLuhT0Xg8wnKCHcHUZEWb2aq7FAVAQLyAoGjfk6LxHfNRqr FTGuw5tgD6hBo7e++SWFALawJqSlx6/Y4n4sO7jB5ahcJo7NDXpuC9D7MybGOEl30wiQ T+lwwnHPDcn+Ghkja15kZdR/b3MfJHlTxCx8VnwYOQtZMXWGx34U9qaEp59dZOsfuPuP ufpqLqSoY6sNKzfaaIj1YlBPJftaBeZTPtWJzEUofaDnXI0j5gn0fbrb3EhaCvg/UtYs ih6A== X-Gm-Message-State: AOAM533y5atEkn1O890joynPa/rYDaC9VFjBbT7/kuwh0YMVdra+Q6UT pBWN/8xvYzNMJe2uHqtueb1arbkVJwHxQ6w4qxc= X-Google-Smtp-Source: ABdhPJy6ETU+F3n2/Z/DMxj7JbtnUcTPBbf2xcwBCHZX7EW5O1DC1Tqcu9w4o394bpMK4iXxpDnETc/FhB9MCL9wWH0= X-Received: by 2002:a9d:4816:: with SMTP id c22mr12054190otf.358.1608570386116; Mon, 21 Dec 2020 09:06:26 -0800 (PST) MIME-Version: 1.0 References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> In-Reply-To: From: Tom Jones Date: Mon, 21 Dec 2020 09:06:14 -0800 Message-ID: To: Fabien Imbault Cc: Denis , txauth gnap Content-Type: multipart/alternative; boundary="00000000000075f39d05b6fc7ae8" Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 21 Dec 2020 17:06:30 -0000 --00000000000075f39d05b6fc7ae8 Content-Type: text/plain; charset="UTF-8" I tried to warn you about user defined as a role. Perhaps you see why now. if the user is a physician, the data is not about the user, it is about the patient (the RO, but a RO that doesn't own the data). But it is the physician that wants to see the data. Focusing on taxonomy before protocol is not helping to make progress. Peace ..tom On Fri, Dec 18, 2020 at 9:02 AM Fabien Imbault wrote: > Thanks Denis, that's a really useful feedback. I'll review that in more > detail, but something that's really not clear to me is the last one, > subject information. > > 1) is it about the end-user ? or the RO ? (as is the current definition in > V02) > 2) why do we even need to call it subject information ? For instance if > it's about the end-user, it should only be end-user information. > 3) do we want to use entity or subject in the definitions ? (cf RO for > instance). Regarding natural person vs entity we had a discussion on the > mailing list previously. > > Cheers, > Fabien > > On Fri, Dec 18, 2020 at 5:47 PM Denis wrote: > >> FYI, the wiki page is there: >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> FYI first, there is a useful web page where you can find all the ISO >> definitions as well as the text for any ISO standard (up to its definition >> section only): >> https://www.iso.org/obp >> This may provide some ideas and you will notice that a given term may be >> used in different ISO standards with a different definition. >> >> I have nine comments (each one being numbered). >> >> * 1) Current definition of AS*: >> >> The current definition is: >> >> *Authorization Server (AS) * >> Definition: server that grants privileges to a particular end-user >> and that provides them to a client in the form of an access token >> This is fine in general (but see later another comment about it), but the >> word privileges is left undefined. >> >> * 2) Definition of a privilege* >> A suggested "privilege" definition has been proposed in the wiki page: "A >> privilege is the right to perform an operation (or action) on a Resource." >> See also other def >> >> . >> In the "other def.", the term is considered to be a synonym of a >> permission. >> >> ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following : >> >> privilege >> access right >> permission >> authorization to a subject (3.15) >> to access a resource (3.14) >> >> >> Note 1 to entry: Privilege is a necessary but not sufficient >> condition for access. Access occurs when the access request is granted >> according to its access control policy. >> The access control policy is based on >> privileges and may include other environmental factors (e.g. >> time-of-day, location, etc.) >> >> Note 2 to entry: Privileges take the form of data presented by a >> subject or obtained for a subject that is used by a Policy Decision Point >> in order to grant or deny an operation >> that a subject is willing to perform on a >> resource. >> (...) >> I propose the following: >> >> *privilege*: right or attribute associated with an end-user >> with: >> *right*: ability given to an end-user to perform a given >> operation on an object under the control of a RS >> >> *attribute*: characteristics or property related to an end-user >> >> >> >> *3) Definition of a Client * The current definition is: >> *Client * >> Definition: application that consumes resources from one or several >> RSs, possibly requiring a negotiation of access privileges with one or >> several ASs >> >> Note: this specification differentiates between a specific instance >> (the client instance, identified by its public key) and the software >> running the instance >> (the client software). For some kinds of client software, >> there could be many instances of a single piece of client software. >> Example: a client can be a mobile application, a web application, >> etc. >> >> Previously, I proposed: >> >> *Client*: application used by an end-user to interact with an AS >> or a RS >> >> The current definition is missing to indicate who is operating the >> client. It is an end-user, i.e. it is not another application, nor a >> process, nor an entity. >> The definition should capture this point. >> A second point: the current definition is using the wording "requiring a >> negotiation". There is no "negotiation". Either the AS has or has not >> the "access privileges". >> The words "a negotiation of" should be deleted. >> >> This raises the point where this definition of a "Client" is using the >> wording "*access privileges*" whereas the definition of an >> "Authorization Server (AS)" >> is using the word "*privileges*". We should make both definitions >> consistent. I have a slight preference for "access privileges", but I could >> also live with "privileges". >> >> Hence my proposals: >> >> * Client * >> application *operated* *by an end-user *that consumes resources >> from one or several RSs, possibly requiring *access privileges from* one >> or several ASs >> >> * Authorization Server (AS) * >> server that grants *access* privileges to a particular end-user and >> that provides them to a client in the form of an access token >> >> >> *4) Definition of a Resource Server (RS) * >> The current definition is: >> >> * Resource Server (RS) * >> Definition: server that provides operations on *protected *resources; >> such operations require that the client provides valid access tokens issued >> by an AS >> A RS may offer both public resources and protected resources. Valid >> access tokens are only needed for protected resources. >> I propose the following definition while merging the two sentences: >> >> *Resource Server (RS) * >> server that provides operations on resources *where* protected >> operations require that the client provides *one or more* valid access >> tokens issued by *one or more ASs* >> In the above modification I added "*one or more *". I am presuming that >> GNAP will allow the presentation of more that one access token from >> different ASs >> in order to allow an end-user to perform one operation on a protected >> resource. >> >> *5) Definition of Resource Owner* >> >> The current definition is: >> * Resource Owner (RO) * >> Definition: personal or organizational entity that may grant >> privileges on resources it has authority upon >> Note: the act of granting privileges may be manual (i.e. through an >> interaction) or automatic (i.e. through predefined rules). >> >> I don't know what a "personal entity" is but I know what a "natural >> person" is. >> >> Furthermore, a Resource Owner is not granting privileges (or access >> privileges) in the same way an AS is doing. >> >> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where >> Resource Owner (RO) is defined as: >> >> responsible party for the Resource(s) >> Note 1 to entry: The Resource Owner is responsible for granting, >> denying, and revoking Access to Resource(s). >> Note 2 to entry: The responsible Resource Owner is determined by >> the concrete Resource. >> I propose: >> *Resource Owner (RO) * >> *natural person *or organizational 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) or automatic (i.e. through predefined rules). >> >> * 6) Definition of Access Token* >> The current definition is: >> Access token >> Definition: digitally signed data that contains specific rights >> and/or attributes >> Note 1: the access token can be issued to an end-user (usually >> requiring his authentication) and subsequently refreshed. >> The AS usually provides a method for the RO to revoke >> the privileges at any point in time. >> Note 2: an access token may act as a capability (i.e. bearer token) >> or require an additional authentication by binding to a key (i.e. bound >> token) >> The definition is fine, but not the two Notes. >> The second sentence from the Note 1 is stating: "The AS usually provides >> a method for the RO to revoke the privileges at any point in time". >> Revoking "the privileges" is different from revoking an "access token". >> The second sentence of this Note 1 which is supposed to be about access >> token is confusing. >> The privileges may be changed at any point in time using a management >> function. Access tokens can be short-lived and thus don't need to be >> revoked. >> Any call-back from a RS to an AS should be avoided in order to respect >> the user's privacy. >> >> Therefore, I propose to remove the second part of this Note 1 and to >> replace "the" by "a" at the beginning of the first sentence. >> Note 2 is stating: >> Note 2: an access token may act as a capability (i.e. bearer token) >> or require an additional authentication by binding to a key (i.e. bound >> token) >> From the discussion on the list, I believe that we don't consider bearer >> tokens. Note 2 should be removed. >> So my proposal is as follows: >> * Access token * >> digitally signed data that contains specific rights and/or >> attributes >> Note: an access token can be issued to an end-user (usually >> requiring his authentication) and subsequently refreshed. >> >> * 7) Definition of Grant* >> The current definition is: >> * Grant * >> Definition: (verb): to permit, as a privilege given to an end-user >> to exercise some rights and/or assert attributes during a specific >> duration >> Definition: (noun): the act of granting >> >> The words ", as a privilege given to" are unnecessary" >> I propose: >> Grant >> (verb): to permit an end-user to exercise some rights and/or *to* >> assert *some *attributes *at a specific time and *during a specific >> duration >> (noun): the act of granting >> >> >> *8) Definition of Resource* >> The current definition is: >> * Resource * >> Definition: protected API served by a RS and accessed by a client, >> if and only if a valid access token is provided >> This definition is incorrect. This definition would be fine for a >> Protected Resource. Change it into "Protected Resource": >> * Protected Resource * >> protected API served by a RS and *that can be *accessed by a >> client, if and only if a valid access token is provided >> If a definition of a Resource is needed, I propose: >> * Resource * >> public or protected resource from a RS >> >> * 9) Definition of Subject Information * >> The current definition is: >> >> *Subject Information* >> Definition: claim asserted locally by an AS about a person, organization >> or device >> Source: >> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >> (unless we plan to use something specific to GNAP) >> >> This is information returned by an AS about an end-user. >> I would thus simply propose instead: >> >> * Subject Information * >> information returned to a Client by an AS about an end-user >> >> Denis >> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000075f39d05b6fc7ae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I tried to warn you about user defined as a role. Perhaps = you see why now. if the user is a physician, the data is not about the user= , it is about the patient (the RO, but a RO that doesn't own the data).= But it is the physician that wants to see the data. Focusing on taxonomy b= efore protocol is not helping to make progress.
    Peace ..tom


    On Fri, Dec 18, = 2020 at 9:02 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks Denis, that's a rea= lly useful feedback. I'll review that in more detail, but something tha= t's really not clear to me is the last one, subject information.
    1) is it about the end-user ? or the RO ? (as is the current d= efinition in V02)
    2) why do we even need to call it subject infor= mation ? For instance if it's about the end-user, it should only be end= -user information.=C2=A0
    3) do we want to use entity or subject i= n the definitions ? (cf RO for instance). Regarding natural person vs entit= y we had a discussion on the mailing list previously.=C2=A0

    <= /div>
    Cheers,
    Fabien

    On Fri, Dec 18, 2020 at 5:47 PM Den= is <denis.ietf@f= ree.fr> wrote:
    =20 =20 =20

    = FYI, the wiki page is there:=C2=A0 https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ide= as and you will notice that a given term may be used in different ISO standards with a different definition. =C2= =A0

    I have nine comments (each one being numbered).

    1) Current definition of AS    : =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Authorization Server (AS) =
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: server that grants privileges to a particular end-user and= that provides them to a client in the form of an access token
    <= /span>

    This is fine in general (but see later another comment about it), but the word privileges is left undefined. =C2=A0

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page= : "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synon= ym of a permission.     =C2=A0

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

    =C2=A0=C2=A0=C2=A0=C2=A0 privilege =C2=A0
    = =C2=A0=C2=A0=C2=A0 access right
    = =C2=A0=C2=A0=C2=A0 permission
    = =C2=A0=C2=A0=C2=A0 authorization to a subject (3.15) to access a resource (3.14)
    <= /span><= br> =C2=A0=C2=A0=C2=A0 Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs w= hen the access request is granted according to its access control policy.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 T= he access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

    =C2=A0=C2=A0=C2=A0     Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 privilege: right = or attribute associated with an end-user

    with:
    =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 right: ability given t= o an end-user to perform a given operation on an object under the control of a RS

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Client
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: application that consumes reso= urces from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

    =C2=A0=C2=A0=C2=A0=C2=A0 Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
    =C2=A0=C2=A0=C2=A0     Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Client: applic= ation used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

    =C2=A0
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "acc= ess privileges".
    The words "a negotiation of<= /span>" should be deleted.

    This raises the point where this definition of a "Client" is using the wo= rding     "access privileges" whereas the definition of an "Authorization Server (AS)" =
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could = also live with "privileges". =C2=A0

    Hence my proposals:

    =C2=A0=C2=A0=C2=A0=C2=A0 Client
    =C2=A0=C2=A0=C2=A0=C2=A0 application operated     by an end-user     that consumes resources from one or s= everal RSs, possibly requiring access privileges from one or several ASs

    =C2=A0=C2=A0=C2=A0 Authorization Server (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 server that grants access privilege= s to a particular end-user and that provides them to a client in the form of an access token
    =C2=A0
    4) Definition of a Resource Server (RS)

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)

    =C2=A0=C2=A0=C2=A0=C2=A0 = Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server that provides operations on r= esources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the=C2=A0 above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
    =C2=A0
    5) Definition of Resource Owner =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0<= b> Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: personal or organizational ent= ity that may grant privileges on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural pe= rson" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsible party for the Resource(s= )
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 1 to entry: The Resource Owner = is responsible for granting, denying, and revoking Access to Resource(s).
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 2 to entry: The responsible Res= ource Owner is determined by the concrete Resource.

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 natural person or organizational en= tity that may grant or deny operations on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).


    6) Definition of Access Token     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: digitally signed data that con= tains specific rights and/or attributes
    =C2=A0=C2=A0=C2=A0     Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The AS usually p= rovides a method for the RO to revoke the privileges at any point in time.     = =C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from = the Note 1 is stating: "The AS usual= ly provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an &= quot;access token". The second sentence of this Note 1 which is supposed t= o be about access token is confusing.
    The privileges may be changed at = any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sent= ence.
    Note 2 is stating:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as foll= ows:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 digitally signed data that contains specif= ic rights and/or attributes =C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0     Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: (verb): to permit, as a privil= ege given to an end-user to exercise some rights and/or assert attributes during a specific duration
    =C2=A0=C2=A0=C2=A0     Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 (verb): to permit an end-user to exercise some rights and/or to assert so= me attributes at a specific time and during a specific duration
    =C2=A0=C2=A0=C2=A0 (noun): the act of granting
    =C2=A0
    =C2=A0
    8) Definition of Resource =C2=A0

    The current definition is= :

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definition: protected API served by = a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

    =C2=A0=C2=A0=C2=A0=C2= =A0 Protected Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 protected API served by a RS and that c= an be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 public or protected resource fr= om a RS


    9) Definition of Subject Information

    The current definition is:
    =C2=A0
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.o= rg/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propo= se instead:

    =C2=A0=C2=A0=C2=A0=C2=A0 Subject Information
    =C2=A0=C2=A0=C2=A0=C2=A0 information returned to a Client by an AS = about an end-user
    =C2=A0
    Denis

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --00000000000075f39d05b6fc7ae8-- From nobody Mon Dec 21 09:18:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99073A1256 for ; Mon, 21 Dec 2020 09:18:51 -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 kfIOIUFlH2Ar for ; Mon, 21 Dec 2020 09:18:48 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84E13A1250 for ; Mon, 21 Dec 2020 09:18:48 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id w18so9537208iot.0 for ; Mon, 21 Dec 2020 09:18:48 -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=+0ogVZjLSI7e/ruQOpAM4mnsxrh8+71umzD4AFA5n60=; b=qzlSx4VTVDVjJXWkxKg3gwujrhFjoek0jEe0rzvgpFKkIEDwQchrvmc6nM9cIbXsPa WU3Pv8MMvYZw2yTUsrZMt4BjWtwBGoKF88Obr4+Z+i0OBB9PM4H/36PmYMXRygmx7spl FXl/QJJ1FGlWxYP/02QOJ4fH3LvY3KHTnImtHYBcxOjfj7f1xXzC26+c7yMq+6a2WWch HBl+q3kgu7vcJNP2d6LCgH1MEfw8oD1apCsXjC8gB6UFFeDTCV++nSDdfYVcD2UimzLd haUZvnoxbdXvUc6M4ukvTzkvuRznPi+XscNbbtUKwscqD7HEHX3On8QrKPzArdS0vZIo Wq4A== 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=+0ogVZjLSI7e/ruQOpAM4mnsxrh8+71umzD4AFA5n60=; b=ezrQpOlvWogDMW55M/npjIkzgX65WQgQRWd66/hNCwWMiL6VsW31xl6DslRFNutec/ kZJ6WuqtBi92ZNCW+6JgKncsiiuCxeYuYMjUSnZoT6V9hKXMl1/uXZxs4CUt4BPFajex +eN+VWeImFQzRA72iW6MktaVVK28r+j8KGLB5yzrSfFXziGtgbh7cCcGRBdD5snilRos W3RtuDtCRCJfPBXhNEAserP89muQzRH8OuOPFv07nqeY1U3sG7WiX7mE7uNdj38EAcZa JEJ94kK6Rr18eRBIdLBdHY0wIyIaj+9Hb5Rjnco/Q/XzX633rzXrMU18ioY8TIkgaswM LlGA== X-Gm-Message-State: AOAM533tCKwKQPAUJGdFwMBzRKfW1wVSbPOz+DiYog3laCQHnwloxbb4 058/2WQfAXW+DltWubXbiIyDEFW+M1zLpRbVPQs= X-Google-Smtp-Source: ABdhPJxJu2IFx7q5lmJF5WbNB/hYnh16m58VwwJTJ1RfOYV8Gjv8notlhITgc0E/xcccneOIoQFsg3i4R7XSDWNGd54= X-Received: by 2002:a5e:a815:: with SMTP id c21mr14645608ioa.141.1608571127747; Mon, 21 Dec 2020 09:18:47 -0800 (PST) MIME-Version: 1.0 References: <17e16653-178a-3f55-1e19-b9b5e055f46e@free.fr> In-Reply-To: From: Fabien Imbault Date: Mon, 21 Dec 2020 18:18:34 +0100 Message-ID: To: Tom Jones Cc: Denis , txauth gnap Content-Type: multipart/alternative; boundary="000000000000aa5aa305b6fca6b5" Archived-At: Subject: Re: [GNAP] Comments on the GNAP Wiki Terminology 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, 21 Dec 2020 17:18:52 -0000 --000000000000aa5aa305b6fca6b5 Content-Type: text/plain; charset="UTF-8" Well, we need a starting point, and a basic taxonomy is helpful as we can have a common vocabulary throughout the protocol. Of course the protocol is the main objective, and we might need to revise the taxonomy based on what is really specified later on. I'll prepare a PR so that we can have that initial terminology section and move forward. Fabien On Mon, Dec 21, 2020 at 6:06 PM Tom Jones wrote: > I tried to warn you about user defined as a role. Perhaps you see why now. > if the user is a physician, the data is not about the user, it is about the > patient (the RO, but a RO that doesn't own the data). But it is the > physician that wants to see the data. Focusing on taxonomy before protocol > is not helping to make progress. > Peace ..tom > > > On Fri, Dec 18, 2020 at 9:02 AM Fabien Imbault > wrote: > >> Thanks Denis, that's a really useful feedback. I'll review that in more >> detail, but something that's really not clear to me is the last one, >> subject information. >> >> 1) is it about the end-user ? or the RO ? (as is the current definition >> in V02) >> 2) why do we even need to call it subject information ? For instance if >> it's about the end-user, it should only be end-user information. >> 3) do we want to use entity or subject in the definitions ? (cf RO for >> instance). Regarding natural person vs entity we had a discussion on the >> mailing list previously. >> >> Cheers, >> Fabien >> >> On Fri, Dec 18, 2020 at 5:47 PM Denis wrote: >> >>> FYI, the wiki page is there: >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >>> FYI first, there is a useful web page where you can find all the ISO >>> definitions as well as the text for any ISO standard (up to its definition >>> section only): >>> https://www.iso.org/obp >>> This may provide some ideas and you will notice that a given term may be >>> used in different ISO standards with a different definition. >>> >>> I have nine comments (each one being numbered). >>> >>> * 1) Current definition of AS*: >>> >>> The current definition is: >>> >>> *Authorization Server (AS) * >>> Definition: server that grants privileges to a particular end-user >>> and that provides them to a client in the form of an access token >>> This is fine in general (but see later another comment about it), but >>> the word privileges is left undefined. >>> >>> * 2) Definition of a privilege* >>> A suggested "privilege" definition has been proposed in the wiki page: "A >>> privilege is the right to perform an operation (or action) on a Resource." >>> See also other def >>> >>> . >>> In the "other def.", the term is considered to be a synonym of a >>> permission. >>> >>> ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following : >>> >>> privilege >>> access right >>> permission >>> authorization to a subject (3.15) >>> to access a resource (3.14) >>> >>> >>> Note 1 to entry: Privilege is a necessary but not sufficient >>> condition for access. Access occurs when the access request is granted >>> according to its access control policy. >>> The access control policy is based on >>> privileges and may include other environmental factors (e.g. >>> time-of-day, location, etc.) >>> >>> Note 2 to entry: Privileges take the form of data presented by a >>> subject or obtained for a subject that is used by a Policy Decision Point >>> in order to grant or deny an operation >>> that a subject is willing to perform on a >>> resource. >>> (...) >>> I propose the following: >>> >>> *privilege*: right or attribute associated with an end-user >>> with: >>> *right*: ability given to an end-user to perform a given >>> operation on an object under the control of a RS >>> >>> *attribute*: characteristics or property related to an end-user >>> >>> >>> >>> *3) Definition of a Client * The current definition is: >>> *Client * >>> Definition: application that consumes resources from one or several >>> RSs, possibly requiring a negotiation of access privileges with one or >>> several ASs >>> >>> Note: this specification differentiates between a specific instance >>> (the client instance, identified by its public key) and the software >>> running the instance >>> (the client software). For some kinds of client software, >>> there could be many instances of a single piece of client software. >>> Example: a client can be a mobile application, a web application, >>> etc. >>> >>> Previously, I proposed: >>> >>> *Client*: application used by an end-user to interact with an AS >>> or a RS >>> >>> The current definition is missing to indicate who is operating the >>> client. It is an end-user, i.e. it is not another application, nor a >>> process, nor an entity. >>> The definition should capture this point. >>> A second point: the current definition is using the wording "requiring >>> a negotiation". There is no "negotiation". Either the AS has or has not >>> the "access privileges". >>> The words "a negotiation of" should be deleted. >>> >>> This raises the point where this definition of a "Client" is using the >>> wording "*access privileges*" whereas the definition of an >>> "Authorization Server (AS)" >>> is using the word "*privileges*". We should make both definitions >>> consistent. I have a slight preference for "access privileges", but I could >>> also live with "privileges". >>> >>> Hence my proposals: >>> >>> * Client * >>> application *operated* *by an end-user *that consumes resources >>> from one or several RSs, possibly requiring *access privileges from* >>> one or several ASs >>> >>> * Authorization Server (AS) * >>> server that grants *access* privileges to a particular end-user >>> and that provides them to a client in the form of an access token >>> >>> >>> *4) Definition of a Resource Server (RS) * >>> The current definition is: >>> >>> * Resource Server (RS) * >>> Definition: server that provides operations on *protected *resources; >>> such operations require that the client provides valid access tokens issued >>> by an AS >>> A RS may offer both public resources and protected resources. Valid >>> access tokens are only needed for protected resources. >>> I propose the following definition while merging the two sentences: >>> >>> *Resource Server (RS) * >>> server that provides operations on resources *where* protected >>> operations require that the client provides *one or more* valid access >>> tokens issued by *one or more ASs* >>> In the above modification I added "*one or more *". I am presuming >>> that GNAP will allow the presentation of more that one access token from >>> different ASs >>> in order to allow an end-user to perform one operation on a protected >>> resource. >>> >>> *5) Definition of Resource Owner* >>> >>> The current definition is: >>> * Resource Owner (RO) * >>> Definition: personal or organizational entity that may grant >>> privileges on resources it has authority upon >>> Note: the act of granting privileges may be manual (i.e. through an >>> interaction) or automatic (i.e. through predefined rules). >>> >>> I don't know what a "personal entity" is but I know what a "natural >>> person" is. >>> >>> Furthermore, a Resource Owner is not granting privileges (or access >>> privileges) in the same way an AS is doing. >>> >>> It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where >>> Resource Owner (RO) is defined as: >>> >>> responsible party for the Resource(s) >>> Note 1 to entry: The Resource Owner is responsible for granting, >>> denying, and revoking Access to Resource(s). >>> Note 2 to entry: The responsible Resource Owner is determined by >>> the concrete Resource. >>> I propose: >>> *Resource Owner (RO) * >>> *natural person *or organizational 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) or automatic (i.e. through predefined rules). >>> >>> * 6) Definition of Access Token* >>> The current definition is: >>> Access token >>> Definition: digitally signed data that contains specific rights >>> and/or attributes >>> Note 1: the access token can be issued to an end-user (usually >>> requiring his authentication) and subsequently refreshed. >>> The AS usually provides a method for the RO to revoke >>> the privileges at any point in time. >>> Note 2: an access token may act as a capability (i.e. bearer token) >>> or require an additional authentication by binding to a key (i.e. bound >>> token) >>> The definition is fine, but not the two Notes. >>> The second sentence from the Note 1 is stating: "The AS usually >>> provides a method for the RO to revoke the privileges at any point in time". >>> Revoking "the privileges" is different from revoking an "access token". >>> The second sentence of this Note 1 which is supposed to be about access >>> token is confusing. >>> The privileges may be changed at any point in time using a management >>> function. Access tokens can be short-lived and thus don't need to be >>> revoked. >>> Any call-back from a RS to an AS should be avoided in order to respect >>> the user's privacy. >>> >>> Therefore, I propose to remove the second part of this Note 1 and to >>> replace "the" by "a" at the beginning of the first sentence. >>> Note 2 is stating: >>> Note 2: an access token may act as a capability (i.e. bearer >>> token) or require an additional authentication by binding to a key >>> (i.e. bound token) >>> From the discussion on the list, I believe that we don't consider bearer >>> tokens. Note 2 should be removed. >>> So my proposal is as follows: >>> * Access token * >>> digitally signed data that contains specific rights and/or >>> attributes >>> Note: an access token can be issued to an end-user (usually >>> requiring his authentication) and subsequently refreshed. >>> >>> * 7) Definition of Grant* >>> The current definition is: >>> * Grant * >>> Definition: (verb): to permit, as a privilege given to an end-user >>> to exercise some rights and/or assert attributes during a specific >>> duration >>> Definition: (noun): the act of granting >>> >>> The words ", as a privilege given to" are unnecessary" >>> I propose: >>> Grant >>> (verb): to permit an end-user to exercise some rights and/or *to* >>> assert *some *attributes *at a specific time and *during a specific >>> duration >>> (noun): the act of granting >>> >>> >>> *8) Definition of Resource* >>> The current definition is: >>> * Resource * >>> Definition: protected API served by a RS and accessed by a client, >>> if and only if a valid access token is provided >>> This definition is incorrect. This definition would be fine for a >>> Protected Resource. Change it into "Protected Resource": >>> * Protected Resource * >>> protected API served by a RS and *that can be *accessed by a >>> client, if and only if a valid access token is provided >>> If a definition of a Resource is needed, I propose: >>> * Resource * >>> public or protected resource from a RS >>> >>> * 9) Definition of Subject Information * >>> The current definition is: >>> >>> *Subject Information* >>> Definition: claim asserted locally by an AS about a person, >>> organization or device >>> Source: >>> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-06 >>> (unless we plan to use something specific to GNAP) >>> >>> This is information returned by an AS about an end-user. >>> I would thus simply propose instead: >>> >>> * Subject Information * >>> information returned to a Client by an AS about an end-user >>> >>> Denis >>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000aa5aa305b6fca6b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Well, we need a starting point,=C2=A0and a basic taxonomy = is helpful as we can have a common vocabulary throughout=C2=A0the protocol.= =C2=A0
    Of course the protocol is the main objective, and we might need = to revise the taxonomy based on what is really specified later on.

    I'll prepare a PR so that we can have that initial ter= minology section and move forward.

    Fabien

    On Mon, Dec 21, 2020 at 6:06 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    I tried to= warn you about user defined as a role. Perhaps you see why now. if the use= r is a physician, the data is not about the user, it is about the patient (= the RO, but a RO that doesn't own the data). But it is the physician th= at wants to see the data. Focusing on taxonomy before protocol is not helpi= ng to make progress.
    Peace ..tom


    On Fri, Dec 18, 2020 at 9:02 = AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Thanks Denis, that's = a really useful feedback. I'll review that in more detail, but somethin= g that's really not clear to me is the last one, subject information.
    1) is it about the end-user ? or the RO ? (as is the curr= ent definition in V02)
    2) why do we even need to call it subject = information ? For instance if it's about the end-user, it should only b= e end-user information.=C2=A0
    3) do we want to use entity or subj= ect in the definitions ? (cf RO for instance). Regarding natural person vs = entity we had a discussion on the mailing list previously.=C2=A0
    =
    Cheers,
    Fabien

    On Fri, Dec 18, 2020 at 5:47 P= M Denis <denis.i= etf@free.fr> wrote:
    =20 =20 =20

    = FYI, the wiki page is there:=C2=A0 https://github.com/ietf-wg-gnap/gnap-core-pr= otocol/wiki/Terminology

    FYI first, there is a useful web page where you can find all the ISO definitions as well as the text for any ISO standard (up to its definition section only):
    https://www.iso.org/obp

    This may provide some ide= as and you will notice that a given term may be used in different ISO standards with a different definition. =C2= =A0

    I have nine comments (each one being numbered).

    1) Current definition of AS    : =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Authorization Server (AS) =
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: server that grants privileges to a particular end-user and= that provides them to a client in the form of an access token
    <= /span>

    This is fine in general (but see later another comment about it), but the word privileges is left undefined. =C2=A0

    2) Definition of a privilege

    A suggested "privilege" definition has been proposed in the wiki page= : "A privilege is the right to perform an operation (or action) on a Resource." See also other def .
    In the "other def.", the term is considered to be a synon= ym of a permission.     =C2=A0

    ISO/IEC 29146:2016(en), 3.8 (very long) definition is the following :

    =C2=A0=C2=A0=C2=A0=C2=A0 privilege =C2=A0
    = =C2=A0=C2=A0=C2=A0 access right
    = =C2=A0=C2=A0=C2=A0 permission
    = =C2=A0=C2=A0=C2=A0 authorization to a subject (3.15) to access a resource (3.14)
    <= /span><= br> =C2=A0=C2=A0=C2=A0 Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs w= hen the access request is granted according to its access control policy.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 T= he access control policy is based on privileges and may include other environmental factors (e.g. time-of-day, location, etc.)

    =C2=A0=C2=A0=C2=A0     Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a Policy Decision Point in order to grant or deny an operation
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a subject is willing to perform on a resource    .
    (...)

    I propose the following:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 privilege: right = or attribute associated with an end-user

    with:
    =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 right: ability given t= o an end-user to perform a given operation on an object under the control of a RS

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     attribute: characteristics or property related to an end-user

    3) Definition of a Client

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Client
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: application that consumes reso= urces from one or several RSs, possibly requiring a negotiation of access privileges with one or several ASs

    =C2=A0=C2=A0=C2=A0=C2=A0 Note: this specification differentiates between a specific instance (the client instance, identified by its public key) and the software running the instance
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (the client software). For some kinds of client software, there could be many instances of a single piece of client software.
    =C2=A0=C2=A0=C2=A0     Example: a client can be a mobile application, a web application, etc.

    Previously, I proposed:
    =C2=A0
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Client: applic= ation used by an end-user to interact with an AS or a RS

    The current definition is missing to indicate who is operating the client. It is an end-user, i.e. it is not another application, nor a process, nor an entity.
    The definition should capture this point.

    =C2=A0
    A second point: the current definition is using the wording "requiring a negotiation". There is no "negotiation". Either the AS has or has not the "acc= ess privileges".
    The words "a negotiation of<= /span>" should be deleted.

    This raises the point where this definition of a "Client" is using the wo= rding     "access privileges" whereas the definition of an "Authorization Server (AS)" =
    is using the word "privileges". We should make both definitions consistent. I have a slight preference for "access privileges", but I could = also live with "privileges". =C2=A0

    Hence my proposals:

    =C2=A0=C2=A0=C2=A0=C2=A0 Client
    =C2=A0=C2=A0=C2=A0=C2=A0 application operated     by an end-user     that consumes resources from one or s= everal RSs, possibly requiring access privileges from one or several ASs

    =C2=A0=C2=A0=C2=A0 Authorization Server (AS)
    =C2=A0=C2=A0=C2=A0=C2=A0 server that grants access privilege= s to a particular end-user and that provides them to a client in the form of an access token
    =C2=A0
    4) Definition of a Resource Server (RS)

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)

    =C2=A0=C2=A0=C2=A0=C2=A0 = Definition: server that provides operations on protected resources; such operations require that the client provides valid access tokens issued by an AS

    A RS may offer both public resources and protected resources. Valid access tokens are only needed for protected resources.
    I propose the following definition while merging the two sentences:


    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Resource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server that provides operations on r= esources where protected operations require that the client provides one or more valid access tokens issued by one or more ASs

    In the=C2=A0 above modification I added "one or more ". I am presuming that GNAP will allow the presentation of more that one access token from different ASs
    in order to allow an end-user to perform one operation on a protected resource.
    =C2=A0
    5) Definition of Resource Owner =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0<= b> Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: personal or organizational ent= ity that may grant privileges on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting privileges may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).

    I don't know what a "personal entity" is but I know what a "natural pe= rson" is.

    Furthermore, a Resource Owner is not granting privileges (or access privileges) in the same way an AS is doing.

    It is interesting to take a look at ISO 20078-1:2019(en), 3.1.4 where Resource Owner (RO) is defined as:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsible party for the Resource(s= )
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 1 to entry: The Resource Owner = is responsible for granting, denying, and revoking Access to Resource(s).
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note 2 to entry: The responsible Res= ource Owner is determined by the concrete Resource.

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Resource Owner (RO)
    =C2=A0=C2=A0=C2=A0=C2=A0 natural person or organizational en= tity that may grant or deny operations on resources it has authority upon
    =C2=A0=C2=A0=C2=A0     Note: the act of granting or denying an operation may be manual (i.e. through an interaction) or automatic (i.e. through predefined rules).


    6) Definition of Access Token     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2=A0 = Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: digitally signed data that con= tains specific rights and/or attributes
    =C2=A0=C2=A0=C2=A0     Note 1: the access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The AS usually p= rovides a method for the RO to revoke the privileges at any point in time.     = =C2=A0=C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    The definition is fine, but not the two Notes.

    The second sentence from = the Note 1 is stating: "The AS usual= ly provides a method for the RO to revoke the privileges at any point in time".
    Revoking "the privileges" is different from revoking an &= quot;access token". The second sentence of this Note 1 which is supposed t= o be about access token is confusing.
    The privileges may be changed at = any point in time using a management function. Access tokens can be short-lived and thus don't need to be revoked.
    Any call-back from a RS to an AS should be avoided in order to respect the user's privacy.

    Therefore, I propose to remove the second part of this Note 1 and to replace "the" by "a" at the beginning of the first sent= ence.
    Note 2 is stating:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     Note 2: an access token may act as a capability (i.e. bearer token) or require an additional authentication by binding to a key (i.e. bound token)

    From the discussion on the list, I believe that we don't consider bearer tokens. Note 2 should be removed.

    So my proposal is as foll= ows:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Access token
    =C2=A0=C2=A0=C2=A0=C2=A0 digitally signed data that contains specif= ic rights and/or attributes =C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0     Note: an access token can be issued to an end-user (usually requiring his authentication) and subsequently refreshed.


    7) Definition of Grant     =C2=A0

    The current definition is:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 Definition: (verb): to permit, as a privil= ege given to an end-user to exercise some rights and/or assert attributes during a specific duration
    =C2=A0=C2=A0=C2=A0     Definition: (noun): the act of granting

    The words ", as a privilege given to" are unnecessary"

    I propose:

    =C2=A0=C2=A0=C2=A0=C2=A0 Grant
    =C2=A0=C2=A0=C2=A0=C2=A0 (verb): to permit an end-user to exercise some rights and/or to assert so= me attributes at a specific time and during a specific duration
    =C2=A0=C2=A0=C2=A0 (noun): the act of granting
    =C2=A0
    =C2=A0
    8) Definition of Resource =C2=A0

    The current definition is= :

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definition: protected API served by = a RS and accessed by a client, if and only if a valid access token is provided

    This definition is incorrect. This definition would be fine for a Protected Resource. Change it into "Protected Resource":

    =C2=A0=C2=A0=C2=A0=C2= =A0 Protected Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 protected API served by a RS and that c= an be accessed by a client, if and only if a valid access token is provided

    If a definition of a Resource is needed, I propose:

    =C2=A0=C2=A0=C2=A0=C2= =A0 Resource
    =C2=A0=C2=A0=C2=A0=C2=A0 public or protected resource fr= om a RS


    9) Definition of Subject Information

    The current definition is:
    =C2=A0
    Subject Information
    Definition: claim asserted locally by an AS about a person, organization or device
    Source: https://tools.ietf.o= rg/html/draft-ietf-secevent-subject-identifiers-06 (unless we plan to use something specific to GNAP)

    This is information returned by an AS about an end-user.

    I would thus simply propo= se instead:

    =C2=A0=C2=A0=C2=A0=C2=A0 Subject Information
    =C2=A0=C2=A0=C2=A0=C2=A0 information returned to a Client by an AS = about an end-user
    =C2=A0
    Denis

    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000aa5aa305b6fca6b5-- From nobody Mon Dec 21 10:10:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601313A133C for ; Mon, 21 Dec 2020 10:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 T2sz2kxmczVw for ; Mon, 21 Dec 2020 10:09:58 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650110.outbound.protection.outlook.com [40.107.65.110]) (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 7BB093A1266 for ; Mon, 21 Dec 2020 10:09:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IJljrxHnRo60CVa9Z0EhddlvjrnRgVK/7RD3jG+4s4yS6WCv3nDjK6TQDjIkqKVMS7T6muCIa7RlVIncJ6UCB5gcoaZqQdokMnAkIOtFJ708L+N0sOyf0CUL6Q0wrI+0aCTdbbWLKZ5PhdXCC9DgkvhrSAXsIUgpLcgX0d/vafuwD1uP4qMLVJde4gCj8aRwIP1Rr+nqzl4FW5+ywY0BbAPbOoSLhkwJiFtqDxUCkzOx4BUHKDe7mCrt9vM5az+EO1Hcs1uGYCXU27o8PXdmZNqBjUWwZoweBkW7lw/Rm4JasPnFkuocYpfhKuG1yeGl9J+TkACzpiIfTTOu2D8hbw== 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=9ViaJHGXJ+VPfv29Jss9elyfRugSat+o5WcYb88LQ8M=; b=XuACHa/2SiLNr2o61CpeB6RQP417Zs67tGKBzvHsGhJY1+yTM2o73qgmbhGUH2CfMOadML3NtR7uZ6+o1MLgjczd99QXUB58DzneR92lOC6LsLyR2e0ZGiiYd1+8w1/YMLRAse8eSc2YWwIa16k26qz2ZktzypQx6fnzQevQW6FGIfeILQDAi8v+zGmxAQY2tllWRoQPe0XbJuyIlle6vZ9dAGIuYttPgbgcE+j8jJenAlo/Kxax+iP/Mo5uzgbAY8lwUlA6SrTFkNjWhsvIFI53K87guP8VMcxSzgUrtSnEnJrwVe+pWD+GfgQ0AnrcyuSubdkKcre69pT9OqiLyw== 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=9ViaJHGXJ+VPfv29Jss9elyfRugSat+o5WcYb88LQ8M=; b=KEnlzh/LzvI6R+qSB4lHUiIZu3FhxSozk3OMHZjalPLGA8h2ZHPKbkH7zT6W71glQIBoLAUg9ZgcBY9H7vDOT8i4GgjJLVGYILrY0iMLdjSaoKuhiBJ+y3rg/feY5mfsVXhNutdUGYgODtoJGrx4n8jhYeUTPzCIglo9mXLqeVQ= Received: from (2603:10b6:a03:ab::28) by BY5PR00MB0659.namprd00.prod.outlook.com (2603:10b6:a03:20c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3731.0; Mon, 21 Dec 2020 18:09:44 +0000 Received: from BYAPR00MB0645.namprd00.prod.outlook.com ([fe80::21d8:62ca:465a:7f28]) by BYAPR00MB0645.namprd00.prod.outlook.com ([fe80::21d8:62ca:465a:7f28%3]) with mapi id 15.20.3734.000; Mon, 21 Dec 2020 18:09:44 +0000 From: Tim Cappalli To: "dave.tonge@moneyhub.com" , "jricher@mit.edu" CC: "txauth@ietf.org" Thread-Topic: [GNAP] Build Previews on GitHub Thread-Index: AQHW1L50gGG7u12oj0ag9u+sy51ZBqn8glwAgAVdBXc= Date: Mon, 21 Dec 2020 18:09:44 +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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-12-21T18:09:33.0601640Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: moneyhub.com; dkim=none (message not signed) header.d=none; moneyhub.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [100.0.202.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 52803687-a218-4f29-04f1-08d8a5db9870 x-ms-traffictypediagnostic: BY5PR00MB0659: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EVQjc/mxaW+a47400ybv3p+p5QoOl25ln8ZGPCyXsWu981NRxqXA2Tq5L/E5/dtSLQ2xHgB6cB73CQFewpmIn5tAIwTXH1sbWp4Ja1s0gQgxDm7PVBKuSgzgPhIbc4xB7ypHSCEQhGnJMrjfY4VC94NakWvD7WnkWa1tfVSLtXeR9INpj4BFss+F7olE/EGqVn097xUYc284Pm2fP3wcZxgR9fUzWBNbPClCywBL7syqLfPPTPa4qPGaiHKbPe+iXLXiyJ54nGnaL3IT12AiCrLk5gyRihPm3rcX3Wbb5SVHOx/IBiGTlCjvdC/3q/sA2DvuGfvpy8QdYMM4aU3/YH8lgiLYH2LmI5HhuuAFclUhk4RIQ0o1iV9TKRCSSFJOvneRArfbdzxBfh461R8C9dlwxvCZbOkDrsw+ikQmSJZ+S/q7OVYwF2hjGtn9cE6rEV69ykcnxiuRt46/osnyaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR00MB0645.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(39860400002)(366004)(346002)(396003)(186003)(66574015)(33656002)(66446008)(966005)(2906002)(4326008)(64756008)(52536014)(6506007)(83380400001)(478600001)(10290500003)(53546011)(55016002)(76116006)(8990500004)(9686003)(110136005)(26005)(86362001)(316002)(7696005)(82950400001)(166002)(5660300002)(71200400001)(8676002)(66946007)(66556008)(8936002)(91956017)(82960400001)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?jzv5B/Bq2oGt4jb6Pnjr7ImRuXg4LL/2qZd9D3WUiRC77OD873E+W4xd?= =?Windows-1252?Q?nwSsT7pM88m3vMXRzIRkgETb8h6Eo55eGZEryHT6mz2RSYL6Qi97bj7e?= =?Windows-1252?Q?HqvTybh9OGw4yZrBtlpBU0U5lxOsaEZ5Mewoy1Me4BFZZwofzCSLKnaJ?= =?Windows-1252?Q?MOGNvcVssHJ0qyXVwhcEYFw9VSoiCkc9ATO6ThGyZFkp9AzCM/v5IPQJ?= =?Windows-1252?Q?pzHN/m4/ydkkIjFSlYlxZQeWItVVaekQpIvgSx4web+e8ItKnTnWiUaN?= =?Windows-1252?Q?z2nO7tzbaFo5LMVUhpkenHxoO+/Z+BGUeQRwYZoPM6pbNh8uZiHgk9sW?= =?Windows-1252?Q?o6olU6kPF5NgIoQt/HXEpeD4PAsDSe8uRSutiM7HxlUQHEdPnDnxQTlW?= =?Windows-1252?Q?20CzOu2ohhIzAAcJ4txKCNtex+6IFduGkHZRg9G+gvKbe9FmdRZy0t5b?= =?Windows-1252?Q?FrZsbuZfTKeMT03aIoruBPUQp8s2pGfPbgFj/dZ4FNlXHbgRSe3QCj+0?= =?Windows-1252?Q?2RQqRIW8G9R3T/lZVClO33MOjl+W057moRBYNQoQ3TwKI2ALRkgmNH6q?= =?Windows-1252?Q?i6pXiSvMtM27ysDbhLX7dD2moR1SC/FJknbA9KVDGpFq1hUoFZ8v1jHf?= =?Windows-1252?Q?TLVuwH7VdWUCOLSmJvSYjJE2oZCfi4xBpaNK4cyv8vPD6w7guAqozKji?= =?Windows-1252?Q?EG/fkUT4+56kiKCHl+MNvdgCMPMk+e63oyWLSknN6BwwlwpR7HTNKl+D?= =?Windows-1252?Q?JHBsG4LMPzDyi22HU4pddZYNqd9oYIG6jQ0VjSfiTjH3UqL+nAhjSjyP?= =?Windows-1252?Q?4ndh8vgMeTSPX9KDQscr1E5IgCr7v260qyMOWokJYeQvNwfbdPH1Cqxv?= =?Windows-1252?Q?2NXglBcwQQaX7oqsQTfTIvdJ7T3rL0PMcRJ4wMBwNsO8AWKn7nOPNnOm?= =?Windows-1252?Q?UUQRicXXx+//eCs2uADy5ix9wYqElTHBx6cIoo9VmcjhCSIzP2AQS0ZD?= =?Windows-1252?Q?GdN4+o8x98TEvwAMu/8imBalFY5kYqJ1hsLTXN/Chv59vIvjdpegB/Tn?= =?Windows-1252?Q?Ifc+S0xmm2L4cD9k5kmxHrJrA5K89Vl3QxNxyg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR00MB0645D982860E0EEF770DAAD395C09BYAPR00MB0645namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR00MB0645.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52803687-a218-4f29-04f1-08d8a5db9870 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2020 18:09:44.5405 (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: Nexs9CSHbdSxgkjpv6a8zvwSUoou3VHrtj+dF2b8bdvN5YQvGvb1u/zSacz1MtbkwK6Mlt89ZwheNu8iARHFGQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR00MB0659 Archived-At: Subject: Re: [GNAP] Build Previews on GitHub 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, 21 Dec 2020 18:10:01 -0000 --_000_BYAPR00MB0645D982860E0EEF770DAAD395C09BYAPR00MB0645namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1, this is awesome Justin! From: TXAuth on behalf of Dave Tonge Date: Friday, December 18, 2020 at 03:16 To: Justin Richer Cc: txauth gnap Subject: Re: [GNAP] Build Previews on GitHub Thank you editors, this is very helpful and hopefully can be a model for st= andards development wider than this WG. On Thu, 17 Dec 2020 at 22:48, Justin Richer > wrote: Based on community feedback, the editors have deployed some tools to augmen= t the GitHub repository and increase its usefulness to the working group. First, we=92ve set up a few checks to make sure that branches are properly = tagged and reviewed before a pull request is merged. While no system is per= fect, this should add at least one extra layer of sanity check. Second, we=92ve set up some automated systems so that the document is autom= atically built from the =93main=94 branch whenever a new commit is pushed t= here. In addition, a rendered version of the current state of the repositor= y should always be available at https://gnap-core-protocol-editors-draft.ne= tlify.app/ as long a= s it is building successfully. Furthermore, all future pull requests will now be automatically rendered as= well. This feature has two purposes: it makes sure a commit doesn=92t brea= k the rendering toolchain (a failure will show up on the PR), and it also a= utomatically makes the a rendered version of the changes in the pull reques= t available on a draft URL. For example, the PR that added this functionali= ty is here: https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/151 On that pull request, you=92ll see a comment from the =93github-actions" bo= t with a URL link. This unique URL hosts a copy of the document including a= ll changes in the pull request. IMPORTANT NOTE: All of these automatically deployed documents are provided = as a convenience and are not official working group drafts. The only offici= al drafts are those published in the IETF tool suite, available from the Da= taTracker page: https://datatracker.ietf.org/doc/draft-ietf-gnap-core-proto= col/ In particular, this means that: 1) The editors=92 draft preview is not the working group document, but it i= s the current state of the document in between published revisions. 2) The automatically generated editors=92 draft, and the pull request previ= ews in particular, should not be linked or referenced externally. These URL= s could change or disappear at any time, without warning, for any reason. T= hey are not intended to be archival, and the canonical copy of the current = editors=92 draft will always be the source document in the repository=92s = =93main=94 branch itself. As always, the document can be rendered directly by downloading the reposit= ory and following the build instructions in the README.md file. Thank you all, =97 Justin, Aaron, and Fabien -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- Dave Tonge Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Lim= ited which is authorised and regulated by the Financial Conduct Authority (= "FCA"). Moneyhub Financial Technology is entered on the Financial Services = Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, = company registration number 06909772. Moneyhub Financial Technology Limited= 2020 =A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Brist= ol, BS1 6EA. DISCLAIMER: This email (including any attachments) is subject to copyright,= and the information in it is confidential. Use of this email or of any inf= ormation in it other than by the addressee is unauthorised and unlawful. Wh= ilst reasonable efforts are made to ensure that any attachments are virus-f= ree, it is the recipient's sole responsibility to scan all attachments for = viruses. All calls and emails to and from this company may be monitored and= recorded for legitimate purposes relating to this company's business. Any = opinions expressed in this email (or in any attachments) are those of the a= uthor and do not necessarily represent the opinions of Moneyhub Financial T= echnology Limited or of any other group company. --_000_BYAPR00MB0645D982860E0EEF770DAAD395C09BYAPR00MB0645namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    +1, this is awesome Justin!

     

    From: TXAuth <txauth-b= ounces@ietf.org> on behalf of Dave Tonge <dave.tonge@moneyhub.com>=
    Date: Friday, December 18, 2020 at 03:16
    To: Justin Richer <jricher@mit.edu>
    Cc: txauth gnap <txauth@ietf.org>
    Subject: Re: [GNAP] Build Previews on GitHub

    Thank you editors, this is very helpful and hopefully can = be a model for standards development wider than this WG.<= /p>

     

    On Thu, 17 Dec 2020 at 22:48, Justin Richer <jricher@mit.edu> wrote:

    Based on community feedback, the editors have deploy= ed some tools to augment the GitHub repository and increase its usefulness = to the working group.

     

    First, we=92ve set up a few checks to make sure that= branches are properly tagged and reviewed before a pull request is merged.= While no system is perfect, this should add at least one extra layer of sa= nity check.

     

    Second, we=92ve set up some automated systems so tha= t the document is automatically built from the =93main=94 branch whenever a= new commit is pushed there. In addition, a rendered version of the current= state of the repository should always be available at https://gnap-core-protocol-editors-= draft.netlify.app/ as long as it is building successfully.

     

    Furthermore, all future pull requests will now be au= tomatically rendered as well. This feature has two purposes: it makes sure = a commit doesn=92t break the rendering toolchain (a failure will show up on= the PR), and it also automatically makes the a rendered version of the changes in the pull request available = on a draft URL. For example, the PR that added this functionality is here:<= o:p>

     

     

    On that pull request, you=92ll see a comment from th= e =93github-actions" bot with a URL link. This unique URL hosts a copy= of the document including all changes in the pull request. 

     

    IMPORTANT NOTE: All of these automatically de= ployed documents are provided as a convenience and are not official working group drafts. The only official drafts are = those published in the IETF tool suite, available from the DataTracker page= : https://datatracker.ietf.org/doc/= draft-ietf-gnap-core-protocol/

     

    In particular, this means that:

     

    1) The editors=92 draft preview is not the working g= roup document, but it is the current state of the document in between publi= shed revisions.

     

    2) The automatically generated editors=92 draft, and= the pull request previews in particular, should not be linked or reference= d externally. These URLs could change or disappear at any time, without war= ning, for any reason. They are not intended to be archival, and the canonical copy of the current editors=92 draft wil= l always be the source document in the repository=92s =93main=94 branch its= elf.

     

     

    As always, the document can be rendered directly by = downloading the repository and following the build instructions in the READ= ME.md file. 

     

    Thank you all,

     

     =97 Justin, Aaron, and Fabien

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


     

    --

    Dave Tonge

     

     

    Moneyhub Enterprise is a trading style of Moneyhub Financial= Technology Limited which is authorised and regulated by the Financial Cond= uct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is register= ed in England & Wales, company registration number 06909772. Moneyhub F= inancial Technology Limited 2020 =A9 Moneyhub Enterprise, Regus Building, T= emple Quay, 1 Friary, Bristol, BS1 6EA. 

    DISCLAIMER: This email (including any attachments) is subject t= o copyright, and the information in it is confidential. Use of this email o= r of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made= to ensure that any attachments are virus-free, it is the recipient's sole = responsibility to scan all attachments for viruses. All calls and emails to= and from this company may be monitored and recorded for legitimate purposes relating to this company's business. = Any opinions expressed in this email (or in any attachments) are those of t= he author and do not necessarily represent the opinions of Moneyhub Financi= al Technology Limited or of any other group company.

     

    --_000_BYAPR00MB0645D982860E0EEF770DAAD395C09BYAPR00MB0645namp_-- From nobody Sun Dec 27 00:06:06 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAB03A08A5 for ; Sun, 27 Dec 2020 00:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=OMnZSGFL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h2mTBiUZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ER7o3WqHFXc for ; Sun, 27 Dec 2020 00:06:00 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37D03A089C for ; Sun, 27 Dec 2020 00:06:00 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AE69277B for ; Sun, 27 Dec 2020 02:49:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 27 Dec 2020 02:49:43 -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=um1CF0ezL80vZfiPMaTAADSItj6lx4Ck3w3C9R2mLBY=; b=OMnZSGFL 93qFpJQjoesSPlNOrpySFhhzfL7uIEn9OjRVex6vM0YGGrzv0ob7psfep24TZzo9 MWJxQxzpP7IVx2f4x6ReX7XhTpbeR57Vy14K8durgqvBQwrCzxsTl2ldHpk2QWp0 pj7yTXWARjvDc1MCJjImjnrZSg5JVheUnVL3pa5CX7odUJJsHtHf3DcSAXhReex6 h4H8DzSacGr5gfFLMbXTAM7bMRG+tC30pvQiuqdX0jMj7DIQuPvZJ82vYhmc2hdR ntyML2/d21NlhuZxDcOVSPuoLBLtnrgZZw+ekTg/4gMLthDoHLQ7taP4JY0Z4+ty FqbKBiazRONd7g== 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=um1CF0ezL80vZfiPMaTAADSItj6lx 4Ck3w3C9R2mLBY=; b=h2mTBiUZR6dzi6VAT/oGJY2YiuQz9I7qdBZBrW5gt6+1i W3VyF5EzQ3R5r/1TAiXusYayWmBJFVb51i2/N1DFcOGMywG+lilKZ9Qa+IFwt27L 4kNDSPVcxYdmJRz4QfIFs48ZUuyjt75KZnPBzKKDlytpPbYPDYfr0K2ExheHlTt6 DCkM9bEoGcnP3aHCdyAKQqiJfcfUVIrZnlwCBobbQKMbHUXT89wWKKPaIhwElrBG xXRLWNUPLTY0bt04eWTt31BaDStcY6m3/qcVWR7bS4D8G/OcgYHLaQMhnrP0cdCB Uk/D4KluWmpgWvoa2qUfMdZQy94O1A3fpwilxpsSQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdduiedguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvtdehrd dvfeefnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-573.internal.cloudapp.net (unknown [40.65.205.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F46B24005A for ; Sun, 27 Dec 2020 02:49:43 -0500 (EST) Content-Type: multipart/alternative; boundary="===============2537299938152499305==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20201227074943.2F46B24005A@mailuser.nyi.internal> Date: Sun, 27 Dec 2020 02:49:43 -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, 27 Dec 2020 08:06:05 -0000 --===============2537299938152499305== 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/-4/=F0=9F=92=AC5) 4 issues received 5 new comments: - #111 Key redundancy in DPoP method (1 by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/111=20 - #108 Fragility of JOSE-based signature methods (1 by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/108=20 - #107 Detached-JWS header (2 by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/107=20 - #106 JWS Headers for JOSE-based signature methods (1 by davidgtonge) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/106=20 4 issues closed: - Error mode for short interaction URL https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/53=20 - Redirect to an Arbitrary Shortened URL https://github.com/ietf-wg-gnap/= gnap-core-protocol/issues/121=20 - Cross-Product of Permissions https://github.com/ietf-wg-gnap/gnap-core-= protocol/issues/12=20 - Identify editor's notes that are just comments https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/128=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+1/-4/=F0=9F=92=AC3) 1 pull requests submitted: - Refactor "key" section (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/152=20 3 pull requests received 3 new comments: - #152 Refactor "key" section (1 by github-actions) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/152=20 - #136 Clarify the nature of access requests, closes #12 (1 by github-act= ions) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/136 [Pending Me= rge]=20 - #132 Changed "resource client (RC)" to "client instance" (1 by github-a= ctions) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 [Pending Me= rge]=20 4 pull requests merged: - drop "Redirect to a Shortened URL" https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/139 [Pending Me= rge]=20 - Clarify the nature of access requests, closes #12 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/136 [Pending Me= rge]=20 - Changed "resource client (RC)" to "client instance" https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 [Pending Me= rge]=20 - Remove closed issues from draft text. https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/150 [Editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol --===============2537299938152499305== 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 December 27, 2020

    Events without label "editorial"

    Issues

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

    4 issues received 5 new comments:

    4 issues closed:

    Pull requests

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

    1 pull requests submitted:

    3 pull requests received 3 new comments:

    4 pull requests merged:

    Repositories tracked by this digest:

    --===============2537299938152499305==--
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Tec= hnology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44= (0)117 280 5120
    <= br>
    D= ISCLAIMER: This email (including any attachments) is subject to copyright, = and the information in it is confidential. Use of this email or of any info= rmation in it other than by the addressee is unauthorised and unlawful. Whi= lst reasonable efforts are made to ensure that any attachments are virus-fr= ee, it is the recipient's sole responsibility to scan all attachments f= or viruses. All calls and emails to and from this company may be monitored = and recorded for legitimate purposes relating to this company's busines= s. Any opinions expressed in this email (or in any attachments) are those o= f the author and do not necessarily represent the opinions of Moneyhub Fina= ncial Technology Limited or of any other group company.
    <= /div>

    Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at https://regist= er.fca.org.uk/. Moneyhub Financial Technology is registered in E= ngland & Wales, company registration number 06909772. Moneyhub Financia= l Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Templ= e Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (including any att= achments) is subject to copyright, and the information in it is confidentia= l. Use of this email or of any information in it other than by the addresse= e is unauthorised and unlawful. Whilst reasonable efforts are made to ensur= e that any attachments are virus-free, it is the recipient's sole respo= nsibility to scan all attachments for viruses. All calls and emails to and = from this company may be monitored and recorded for legitimate purposes rel= ating to this company's business. Any opinions expressed in this email = (or in any attachments) are those of the author and do not necessarily repr= esent the opinions of Moneyhub Financial Technology Limited or of any other= group company.


    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --0000000000009fdcc905b675f52e-- From nobody Mon Dec 14 16:46:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347223A12F0 for ; Mon, 14 Dec 2020 16:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RQaoMKA9_6g for ; Mon, 14 Dec 2020 16:46:53 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96383A12ED for ; Mon, 14 Dec 2020 16:46:52 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id t9so17634841ilf.2 for ; Mon, 14 Dec 2020 16:46:52 -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=rtKVZ/2BR1XoOb1bOovAQvTrkrKRA09QzZ8EMtmBviY=; b=gCvf/4MwEScagq02C+kbciCROJdGPWxFMT3tGmO1n3DkLisghGfHB00D4lsckHwUXw kwrxnQr1aYvUJ/109bESa+9SfYBYdA8S8rs2XKlOt+sW7qwf3KkawLMNTREyyVFfKh/h L9VJ1AQmEqsYhoqX9GJkZaNDgDf4Eg6cTnuzGA01yPCFt6HpQtRUUTP1MldVzqwLAulM r51CBd8Qv26JG4hGy/x7lvo3BePCdOu5NLRcd0oveKDxYzXNl8LFAxVI/prkZeNbTv50 OJr8/Krew+YoiUwTuOTCF/eCj//A6a2nGOVyrTONX831caM1sM9U88zSaFTjX3o6Rfa+ flzg== 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=rtKVZ/2BR1XoOb1bOovAQvTrkrKRA09QzZ8EMtmBviY=; b=RGnyc4IC0ni6inlDAfvN9z2c4ZQRatGW5yQicz7kS6ZgmJF9W89AN3J7S1zmNLNXis MjNnL7jsDTwOi9ngq/YIEieR72Zb7WkbuQuJtug/G16xsS1u+5uIEr5HbqcEHOYBpo/2 8V2N0yzBWpJk+aHzdtdz9Scbpfb9Jj2PDT5nB8x8YOBDMK2lWHPpvCsEp5yxPNckCQzT wcZtq5P4ffAnbC5EVXXhNcSEPPHTWV/t9Mjr0TmDt1GDpJqUsIEskkp4r7aEHFFWgSbB doSgZRBaC/MRIG6CBuWWeM6zmQYeB4m0zHGSO2072jpvp5slX/YOMt2YouqH96UQX7Zu 9vzA== X-Gm-Message-State: AOAM530++AiJoXz7X1E8ew0xww3MZoS8r23y74d0uOsa/pO7gGSnhJkM FMqzfhX3CWzTrQSOb3WDDm0NctE41Luzfh0k+LQ= X-Google-Smtp-Source: ABdhPJyusmIFhuzCuZ2vo8PfwlP6jSNu5R2LoPPHwxBvQP8nU5/iicVNXScC5mvLb9IHeg8L9qqahfBzFAj8jEeGwBU= X-Received: by 2002:a92:ce44:: with SMTP id a4mr39159631ilr.178.1607993212252; Mon, 14 Dec 2020 16:46:52 -0800 (PST) MIME-Version: 1.0 References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <8E2FF25A-4BE1-4EA1-A0FE-CB5194DEAC52@mit.edu> In-Reply-To: From: Fabien Imbault Date: Tue, 15 Dec 2020 01:46:39 +0100 Message-ID: To: Dave Tonge Cc: Dick Hardt , Aaron Parecki , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="00000000000037bd7505b676180e" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 00:46:55 -0000 --00000000000037bd7505b676180e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe we'd need to clarify the use cases indeed. A big part of what you're saying is : it can be done differently. Which is true, just not with the same expressiveness. Beyond what we're covering here, I see at least one important service that would directly benefit from tokens, around introspection/management api (e.g. is the token still valid?). Here there's no information lookup about a grant, we could just query a bloom filter if we get the authorization to do so. I agree it's not yet included but it's perfectly feasible. Statelessness can be good for scalability in general, at least if it doesn't come at the expense of something important (which I don't think is the case here). For end developers, it's often much easier to use a URL and pass a token, and not to have to decode the parameters (only HTTP specialists are used to that). That's basically what made JWT successful. As for key presentation, it's the very same mechanism used in the various calls (cf section 2.3 and section 8). But of course when you initialize, you have never reached the server and so there is no state, which I don't think would be difficult to understand by client devs, especially as the calls are already distinct. Le lun. 14 d=C3=A9c. 2020 =C3=A0 22:25, Dave Tonge a =C3=A9crit : > On the call I voiced my opinion that opionality should be reduced in the > spec where possible. At the time I was in favour of access tokens being > required. However, after reading the thread and looking again at the spec > I'm no longer convinced. > > The only advantage I can see of the access token, is that it provides a > way for the AS to be stateless, but I'm not sure how common or desirable > that use-case is? As soon as the AS has to look some information up about= a > grant in order to continue, then there is no benefit in the access token. > The identity of the grant can be in the url, and the authenticity of the > client is provided by the signature. > > I know this is beyond the scope of this pull request, but for the majorit= y > of use-cases, my personal opinion is that a consistent identifier for eac= h > grant and a mandated REST like URL structure would be far more useful. > > The GNAP spec is being designed in an extensible manner that will allow a > huge amount of use cases. Maybe in the future there will be new endpoints > dreamed up at the AS that require tokens. But the current ones described > in the spec don't (create grant, continue grant, modify grant, get grant= , > cancel grant, rotate token & revoke token). > > I also think there is some confusion that "binding" is being used for: > - client authentication > - sender constraining access tokens > - http request signing > > If the signing mechanism is ok to authenticate the client in the first > request, why is it not sufficient to authenticate the client on the > continuation request? > > I think we need a stronger use-case for access tokens at the AS to > warrant even its optional inclusion in the spec. > > On Mon, 14 Dec 2020 at 21:25, Dick Hardt wrote: > >> I don't understand what security risks are unique with the GNAP URI >> relative to other API URIs that have a unique identifier in them. >> >> Developers can get "creative" and put "inappropriate" values in any API >> URI they design. >> >> What are the security implications of using a large random value as the >> ? >> >> >> =E1=90=A7 >> >> On Mon, Dec 14, 2020 at 11:46 AM Aaron Parecki wrote= : >> >>> Thanks for the clear description. However saying "has no security >>> concerns" is a bold claim. Can you clarify how you will ensure that the= re >>> are no security concerns with this method? >>> >>> My main worry with this is people will start to get "creative" with the >>> values of the things in this URL. We've seen this over and over, everyt= hing >>> from using plaintext data in JWT access tokens in OAuth (now the access >>> token contents are visible to clients), to putting data in the OAuth >>> "state" parameter (easy to exploit unless it's signed/encrypted), and I= 'm >>> sure someone somewhere is putting things in the authorization code that >>> they shouldn't. >>> >>> Aaron >>> >>> >>> On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt >>> wrote: >>> >>>> >>>> I am proposing a URI that is straight forward, and has no >>>> security concerns. >>>> >>>> For example, the URI could be: >>>> >>>> /grant/ >>>> >>>> eg: https://example.com/as/grant/a3ce6053-ca48-4c04-af46-c2384ec8b89f >>>> >>>> The routing code in the AS then is: >>>> >>>> router.post( '/', grant.create); >>>> router.get( '/grant/:grant', grant.read); >>>> router.post( '/grant/:grant', grant.update); >>>> router.delete( '/grant/:grant', grant.delete); >>>> router.options( '/grant/:grant', grant.options); >>>> >>>> >>>> Where there is a "grant" module to manage for working with grant >>>> requests. >>>> >>>> /Dick >>>> >>>> ps: your previous email, and this one, are making the discussion >>>> personal. Happy to discuss privately. >>>> >>>> =E1=90=A7 >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > --00000000000037bd7505b676180e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Maybe we'd need to clarify the use cases indeed.= =C2=A0

    A big part of wha= t you're saying is : it can be done differently. Which is true, just no= t with the same expressiveness.=C2=A0

    Beyond what we're covering here, I see at least one impor= tant service that would directly benefit from tokens, around introspection/= management api (e.g. is the token still valid?). Here there's no inform= ation lookup about a grant, we could just query a bloom filter if we get th= e authorization to do so. I agree it's not yet included but it's pe= rfectly feasible.=C2=A0

    = Statelessness can be good for scalability in general, at least if it doesn&= #39;t come at the expense of something important (which I don't think i= s the case here).=C2=A0

    = For end developers, it's often much easier to use a URL and pass a toke= n, and not to have to decode the parameters (only HTTP specialists are used= to that). That's basically what made JWT successful.=C2=A0

    As for key presentation, it's t= he very same mechanism used in the various calls (cf section 2.3 and sectio= n 8). But of course when you initialize, you have never reached the server = and so there is no state, which I don't think would be difficult to und= erstand by client devs, especially as the calls are already distinct.=C2=A0=

    Le lun. 14 d=C3=A9c. 2020 =C3=A0 22:25, Dave= Tonge <dave.tonge@moneyhub.com> a =C3=A9crit=C2=A0:
    On the call I voiced my= opinion that opionality should be reduced in the spec where possible. At t= he time I was in favour of access tokens being required. However, after rea= ding the thread and looking again at the spec I'm no longer convinced.<= /div>

    The only advantage I can see of the access token, is that it= provides a way for the AS to be stateless, but I'm not sure how common= or desirable that use-case is? As soon as the AS has to look some informat= ion up about a grant in order to continue, then there is no benefit in the = access token. The identity of the grant can be in the url, and the authenti= city of the client is provided by the signature.=C2=A0=C2=A0

    I know this is beyond the scope of this pull request, but for the majority= of use-cases, my personal opinion is that a consistent identifier for each= grant and a mandated REST like URL structure would be far more useful.=C2= =A0

    The GNAP spec is being designed in an extensible manner = that will allow a huge amount=C2=A0of use cases. Maybe in the future there = will be new endpoints dreamed up at the AS that require tokens. But the cur= rent ones described in=C2=A0 the spec don't (create grant, continue gra= nt, modify grant, get grant, cancel grant, rotate token & revoke token)= .

    I also think there is some confusion that "bind= ing" is being used for:
    =C2=A0- client authentication
    =C2=A0= - sender constraining access tokens
    =C2=A0- http request signing
    =
    =
    If the signing mechanism is ok to authenticate the client in the = first request, why is it not sufficient to authenticate the client on the c= ontinuation request?

    I think we need a stronger use-case for= access tokens at the AS to warrant=C2=A0even its optional inclusion in the= spec.

    On Mon, 14 Dec 2020 at 21:25, Dick Hardt <dic= k.hardt@gmail.com> wrote:
    I don't understand what security risk= s are unique with the GNAP URI relative to other API URIs that=C2=A0have a = unique identifier=C2=A0in them.=C2=A0

    Developers can= get "creative" and put "inappropriate" values in any A= PI URI they design.

    What are the security implicat= ions of using a large random value as the <unique grant id>?


    3D""=E1=90=A7

    On Mon, Dec 14, 2= 020 at 11:46 AM Aaron Parecki <aaron@parecki.com> wr= ote:
    Thanks for the clear description. However saying "has no securit= y concerns" is a bold claim. Can you clarify how you will ensure that = there are no security concerns with this method?

    My main= worry with this is people will start to get "creative" with the = values of the things in this URL. We've seen this over and over, everyt= hing from using plaintext data in JWT access tokens in OAuth (now the acces= s token contents are visible to clients), to putting data in the OAuth &quo= t;state" parameter (easy to exploit unless it's signed/encrypted),= and I'm sure someone somewhere is putting things in the authorization = code that they shouldn't.

    Aaron

    =

    On Mon, Dec 14, 2020 at 11:39 AM Dick Hardt <dick.h= ardt@gmail.com> wrote:

    I am proposing a URI tha= t is straight forward, and has no security=C2=A0concerns.

    For example, the URI could be:

    <as uri&= gt;/grant/<unique grant id>


    The routing co= de in the AS then is:

    router.post(=C2=A0 =C2=A0 = =C2=A0 '/', grant.create);
    router.get(=C2=A0 =C2=A0 =C2=A0 =C2= =A0 '/grant/:grant', grant.read);
    router.post(=C2=A0 = =C2=A0 =C2=A0 '/grant/:grant', grant.update);
    router.delete(=C2= =A0 =C2=A0'/grant/:grant', grant.delete);
    router.options( '/= grant/:grant', grant.options);

    Where th= ere is a "grant" module to manage for working with grant requests= .

    /Dick

    ps: your previous= email, and this one, are making the discussion personal. Happy to discuss = privately.

    3D""=E1=90=A7
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/lis= tinfo/txauth
    --
    TXAuth mailing list
    TXAuth@ietf.org
    https://www.ietf.org/mailman/lis= tinfo/txauth


    --
    Dave Tonge
    CTO
    3D"Mon=
    Money= hub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is a = trading style of Moneyhub Financial Technology Limited which is authorised = and regulated by the Financial Conduct Authority ("FCA").=C2=A0Mo= neyhub Financial Technology is entered on the Financial Services Register= =C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/. Money= hub=C2=A0Financial Technology is registered in England &am= p; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<= /span>
    Moneyhu= b=C2= =A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email (including any attac= hments) is subject to copyright, and the information in it is confidential.= Use of this email or of any information in it other than by the addressee = is unauthorised and unlawful. Whilst reasonable efforts are made to ensure = that any attachments are virus-free, it is the recipient's sole respons= ibility to scan all attachments for viruses. All calls and emails to and fr= om this company may be monitored and recorded for legitimate purposes relat= ing to this company's business. Any opinions expressed in this email (o= r in any attachments) are those of the author and do not necessarily repres= ent the opinions of Moneyhub Financial Technology Limited or of any other g= roup company.
    <= /div>

    Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct Authority ("FCA"). Moneyhub Financial Technology is entered= on the Financial Services Register (FRN 809360) at h= ttps://register.fca.org.uk/. Moneyhub Financial Technology is re= gistered in England & Wales, company registration number 06909772. Mone= yhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Bu= ilding, Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0

    DISCLAIMER: This email (incl= uding any attachments) is subject to copyright, and the information in it i= s confidential. Use of this email or of any information in it other than by= the addressee is unauthorised and unlawful. Whilst reasonable efforts are = made to ensure that any attachments are virus-free, it is the recipient'= ;s sole responsibility to scan all attachments for viruses. All calls and e= mails to and from this company may be monitored and recorded for legitimate= purposes relating to this company's business. Any opinions expressed i= n this email (or in any attachments) are those of the author and do not nec= essarily represent the opinions of Moneyhub Financial Technology Limited or= of any other group company.


    =
    --00000000000037bd7505b676180e-- From nobody Tue Dec 15 00:50:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB083A0E8D for ; Tue, 15 Dec 2020 00:50:27 -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=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsgeeMV9j6cm for ; Tue, 15 Dec 2020 00:50:25 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 4FA383A0E8A for ; Tue, 15 Dec 2020 00:50:25 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id q22so8759777eja.2 for ; Tue, 15 Dec 2020 00:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4PwmJj34r2Wh2Nt+/8ktbcBEjPD1Kujgptsyy36ljMY=; b=CsmOLJD92R9VnnkcgHgbNbanoGtRlSvZ6C6kBd6WFCBPKBSV60nSGXfut8DIIaHRtQ 8G75h7jnmXazy6GenckmMvYBBMXO4aL13lHXqQAIiUT4+TAgS7olj6pupWvSlpOd5uOo cLw9HaP8NF+2wy/W+3hxtYrx+ELiGvzOib16uB1y3FN6w43XPFh8ZyUceKPIW+5vlDi5 SJAY+Rmb2H011se5Hcx55wxRebqA/mD19VGaI7wlztcO1hKKyiBJjlj3tGzKljJCt4d4 n2Uaxh0XR6t9hLNgaJpR2KUffsocwBsQj8uSrPNkaoCrIPA6obGLdqnMnwFnmTwaVLUZ QFQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4PwmJj34r2Wh2Nt+/8ktbcBEjPD1Kujgptsyy36ljMY=; b=nqFdlWTBUvW+iXXOh64aM3leNSpl1wRknx73TnkZ3m0ISUlNU5UeCyqZcpH9pJ3Bt7 /95wVlngtpO8t3eAdMuVgCioDoT8xvFbyR/u37E4ZObJ0Mmp2aPlH4O08uA4OaZdZPGg 23EeqEIrkPsJrRiYZAseD/0nb6Yms7y+k0DIDxWMG/J2IJer2S0aDEOqwMA8gewC7uld 2RuXovnJSl0iFnpiCX15TNGSFKcKbffBMLA0OEwhVS6+o549U30767vpmLS/M8epBk6p E4AAqMzHvbReDnmZs/B0Q5IX8qshYKL1EJHqZr9umyUcJTTkpL6PJiH+AMHhsBkoScHe +7Aw== X-Gm-Message-State: AOAM533KkMX8gFHLJxpQ8PbWXm2iZUBFJHgBx1AAQttx5N6p20D1mON+ 1O/lXC4iBsb52hvex43RKR91Uw== X-Google-Smtp-Source: ABdhPJxr1iN9jYumJvfS4l4DYULmqsTvjAdCUI7IzlCY7CFgbxpzPzpjfecGe7MoFy/NyMVVM2YuMw== X-Received: by 2002:a17:907:20dc:: with SMTP id qq28mr25533008ejb.403.1608022223383; Tue, 15 Dec 2020 00:50:23 -0800 (PST) Received: from p200300eb8f1bfa6c81abbb74f9a57e62.dip0.t-ipconnect.de (p200300eb8f1bfa6c81abbb74f9a57e62.dip0.t-ipconnect.de. [2003:eb:8f1b:fa6c:81ab:bb74:f9a5:7e62]) by smtp.gmail.com with ESMTPSA id mc25sm839511ejb.58.2020.12.15.00.50.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Dec 2020 00:50:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Torsten Lodderstedt In-Reply-To: Date: Tue, 15 Dec 2020 09:50:21 +0100 Cc: Stephen Moore , txauth gnap , Justin Richer , Dick Hardt Content-Transfer-Encoding: quoted-printable Message-Id: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> References: To: Fabien Imbault X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 08:50:28 -0000 Hi Fabien,=20 > Am 12.12.2020 um 12:06 schrieb Fabien Imbault = : >=20 > Hi, >=20 > On the contrary your feedback is most welcome.=20 >=20 > It doesn't accept any token, it needs the particular token as = described in 3.1 and which is not a bearer token (that's what the "key" = : true parameter is supposed to convey).=20 >=20 > Let us know if you need more clarifications.=20 Thanks for the clarification. I think only accepting this kind of token = at the continuation is a good idea otherwise the AS would need to be = able to parse and understand all sorts of access tokens. Conceptually, I like the idea to treat the continuation as another kind = of resource. However, here are some observations I want to share with = you:=20 - This resource is different as it will issue other access tokens (of = this kind) to be used in subsequent continuation requests. This requires = different handing on the client side. - This access token (if I understand correctly) is (or at least feels = like) a handle for the underlying grant. So it is kind of the super = access token to obtain other access tokens.=20 I would consider using a different term to refer to this special access = token, grant token or grant handle for example, in order to prevent = confusion.=20 best regards, Torsten.=20 >=20 > Best > Fabien=20 >=20 > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt = a =C3=A9crit : > Hi all, >=20 > I didn=E2=80=99t follow GNAP closely so bear with me if me question = seems naive. >=20 > After having skimmed through the current draft and the PR, I=E2=80=98m = not sure whether the continuation requests accepts any access token = issued to the RC or the particular access token returned in the = =E2=80=9Econtinue=E2=80=9C element in section 3.1.. >=20 > Can you please shed some light on this? >=20 > kind regards, > Torsten. >=20 >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault = : >>=20 >> =EF=BB=BF >> You're completely right. Allowing the dev to be lazy is a very good = thing in general, because it's what we know will work :-)=20 >>=20 >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore = a =C3=A9crit : >> Hi Fabien, >>=20 >> For #3) Even after I typed out the hypothetical attack, that was sort = of in the back of my mind, it isn't a huge risk there. So I actually = agree with Dick there. Something doesn't sit right with me for the = unique URL solution, so I don't like it and came up with a hypothetical = that seems like it could be a down side. >>=20 >> I still think the access token model with the signed request is the = way I'd like to go, because again, it's a mechanism I'd be implementing = anyway to talk to any 'normal' resource. The fact is there is = _something_ representing context that has to pass back and forth here, = whether that is an access token (which I feel like is more flexible for = extensions etc), a unique url, or even a cookie sent in the cookie = header. So just to re-iterate, I'm a +1 on this pull request, speaking = as a lazy developer ;) >> -steve >>=20 >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault = wrote: >> Again speaking in my own name here.=20 >>=20 >> Dick, we know you'd prefer to have a different design, but this PR = shouldn't be about that.=20 >>=20 >> Back on your 3 items : >>=20 >> 1) yes we could make pre-register mandatory, but we already decided = that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what = you want)=20 >>=20 >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever = that have the tenancy to flame conversations, I suggest we speak in less = abstract terms and ask ourselves what that means in practice for devs. = Stephen and several others (myself included) have expressed that it = wouldn't be harder to implement, it would even simplify things quite a = lot. If you disagree please send us a code sample to really show that = point by example, because that's really not obvious.=20 >>=20 >> 3) "If someone has the client credentials, they can impersonate the = client, and all bets are off." Are you seriously making this argument? = Because if you have a better proposal than using cryptographic keys, I'm = all hears. You make it look like there's a problem, while in reality = we're only relying on the basic assumption of all modern digital = communications.=20 >> =20 >> And more importantly you never responded to the issues of how to = avoid the security pitfalls of what you proposed.=20 >>=20 >> Fabien=20 >>=20 >>=20 >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = a =C3=A9crit : >>=20 >>=20 >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore = wrote: >> But from the spec: >> " >> When sending a non-continuation request to the AS, the RC MUST = identify itself by including the client field of the request... >> ... >> key (object / string) : The public key of the RC to be used in this = request as described in {{request-key}}. This field is REQUIRED.=20 >> ... >> " >> So on the initial request, the key will be there.=20 >>=20 >> The client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object. >> =20 >>=20 >> If you don't have the access token, then how do you differentiate = between two requests from the same web application by two different = users? Is the web application supposed to have different credentials for = every request? >>=20 >> The AS returns a URI for manipulating the request. I would change the = spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI. >>=20 >> =20 >> So in this case, the easy way out is to pass the access token to the = client, who then, as i stated before, treats the continue request as a = RS call (albeit a specialized version of the RS where the RS is the AS) = OR to use the unique URL,=20 >> but that seems open to a brute force attack by a malicious RC. (What = would be the point of that attack, I don't know, I guess if someone had = the client credentials but not any subjects/resources they could try to = intercept the grant via continue... I just don't feel right locking = things down to unique URLs that way.) >>=20 >> If someone has the client credentials, they can impersonate the = client, and all bets are off. >>=20 >> LOTS of RS servers return a resource specific URL -- my proposal is = no different. >>=20 >>=20 >> =20 >> -steve >>=20 >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt = wrote: >> Hi Stephen >>=20 >> The client is signing the first request. The key *might* be in the = body. The client is signing all the subsequent requests as well. The = "access token" is not needed by the client to prove it is authorized as = the client is proving it is the same client again. >>=20 >> In other words, I don't see the need for an access token, so it does = not need to be put in a URL or an auth header. >>=20 >> If a developer really, really wants to hand context back to the = client for subsequent calls, they can put it in the URL or some other = method. Putting it in the HTTP Authorization header is confusing because = it is NOT an access token -- it is the context of the request. >>=20 >> =E1=90=A7 >>=20 >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore = wrote: >> Even though I've only been lightly following things, I feel the need = to voice my preference as a developer since I will probably someday have = to either write a RC or RS...=20 >>=20 >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of = the Authorization header) >> At this point that request, represented by the continue URL + "Access = Token", from my lazy developer standpoint, is a Resource Endpoint and = Access Token, and the AS is acting as a specialized RS in this case. >> So my client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a = token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client. >> Personally I like that, because if I have an access_token, I already = think "Put it in the auth header."=20 >>=20 >> So my vote would be +1 for the pull request at this time. >> -steve >>=20 >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt = wrote: >> inline ...=20 >>=20 >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer = wrote: >> Others had already responded to this previous thread, but I wanted to = add a couple points to clarify some things. >>=20 >>> 3) What the client has to do with the "access token" is not the same = as access tokens for an RS. The client gets a new "access token" for = each grant request, and for each API call to the AS, and the client = learns it can not make any more API calls for that specific request when = it does not get an "access token" back. This is a completely different = design pattern than calling an RS API with an access token, and is a new = design pattern for calling APIs. This adds complexity to the client that = it would not normally have, and I don't think GNAP is the right place to = start a new design pattern. >>>=20 >>=20 >> I=E2=80=99m not sure what you mean by these being different =E2=80=94 = the whole point of the design is that the client would be doing the same = thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical. >>=20 >> The client is getting the "access token" from its API. It is not = using an "access_token" in other API calls to the AS. >> =20 >>=20 >> Rotation of the access token and artifacts for ongoing continuation = responses is a separate issue to be discussed: = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>=20 >> And for what it=E2=80=99s worth, GNAP is absolutely the right place = to have new designs =E2=80=94 not that this is one. >>=20 >> You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me. >> =20 >>=20 >>> 4) Clients that only want claims from the AS and no access tokens = will be required to support an API calling mechanism they would not have = to support otherwise.=20 >>=20 >> Correct, but the delta between the calls a client would make with and = without an access token is vanishingly small. The client has to sign the = initial request in some fashion, and it will sign the continuation = request in the same exact fashion, but now include an access token in = that request.=20 >>=20 >> Per my other point, there is no value to me in my implementations of = passing context back and forth between the client and AS -- so it is = extra work providing no value. >>=20 >> Also, any client authentication mechanism that wants to use the HTTP = Authentication header is precluded from using it. >>=20 >> =20 >>=20 >> Clients making a request to an AS and not getting an access token is = a new design pattern. I think it has value and should be included, but = OAuth today shows us the immense value of getting access tokens for = calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern. >>=20 >>>=20 >>> 5) If the AS does not provide an "access token", there is no = mechanism for a client to delete the request, as the client is not = allowed to make a call without an "access token". >>=20 >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D = field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. >>=20 >> There is nuance in that intention. A related concern is that deleting = a request does not seem like it is a "continue" operation. >> =20 >>=20 >>>=20 >>> 6) There is no standard identifier for the request. Debugging and = auditing are hampered by the client and AS having no standard way to = identifying a request. While one AS may provide a unique URL for each = grant request, another AS may use a persistent "access token" to = identify the grant request, and other ASs may issue a new "access token" = on each API call, providing no persistent identifier for the request. >>=20 >> Debugging and auditing this kind of thing are functions of the AS. = How is interoperability harmed by different ASs having different methods = to identify their internal data elements? The client doesn=E2=80=99t = need any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps for continuing the negotiation. >>=20 >> Debugging between the client and the AS was what I was referring to. = How does a client developer identify the request when communicating to = the AS developer. Seems complicated. >> =20 >> =E1=90=A7 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> =E1=90=A7 >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> --=20 >> TXAuth mailing list >> TXAuth@ietf.org >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJ= YtSpI From nobody Tue Dec 15 01:11:14 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6D3A0E72 for ; Tue, 15 Dec 2020 01:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3e9GVTllZnn for ; Tue, 15 Dec 2020 01:11:10 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D694F3A0E14 for ; Tue, 15 Dec 2020 01:11:09 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id p187so19774161iod.4 for ; Tue, 15 Dec 2020 01:11: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=kpHmlPSMssHA9JQxz4aNHs34uriCHX1KKNg6H4+MsOA=; b=B9WFfr0mS/LGldy75tagn01PvvTr5y8OfWy5bR3ua3Njec3ee1ORkuy78t3cbOpv/r PDRseWD7CFmpAhsBux2NoVBDovrL4UGiiK1XmCweOVmEx9pPc/Bmwl8qoRR5Dp9xJz0K kqOH0f4+rgCCsxY0+8jWIL8yx88M7EtekHYxpKecUgNAtjqd9PQhxF9G77F8Ok9xiPT7 YZ34LVYj97D1CaUya6QBlsvefz6tjAy56Wo1cMf6IYY6hmLiGJWwENWT+J4nCEmBG3bN mt6j6W9pSNo7OHk07O7QatxYiCJQynePMwVfgnQPfses/hozcSIqe9FZxcM5BqhN2uYo iFSg== 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=kpHmlPSMssHA9JQxz4aNHs34uriCHX1KKNg6H4+MsOA=; b=HHLuwJeYfH2v2SjF8VqoVUqHRg6V7Mhx3a0fX1TyUk/3xfh5DL6zS6bI0zDn7YVmgr qMWKZCbVuiRGT+ryUPyoW7mBhuCxPJyrUzZRfVSOrXgegnOuKweHXLydGZeBPEzyWwzJ 1/GWNQEjGgX566gg7CU3xLdalgJcOulHfjFwGp4HXK/qMSffD/5lOMp4y4yMEsRpixuz MFe0c5/xBp5TwuevWuMCpYcAXABKURxq5LTepxVO7LUttWRcDsstNRYGefW8EP3N+Sei w0SVRcEJvpqygnqk4Z8aE5lQNRjPGdxawfk4AIGDaQDb9OBFbkLx9+B2dnXBF/9Z1HDm u6Tg== X-Gm-Message-State: AOAM530wP+DeU7qaxxqhhME/BN+awhVJiF+in95Ic1p+RLZ70fFvHBZQ e0RDkM5007dkCyCqFtuouVICqyfF40a1hOULjMYF+vPh73Hrbg== X-Google-Smtp-Source: ABdhPJwsJROoQcynzz/a4dXfQdmjdyBgqzbfKs2DxQpTdpp/OlQ3fj2Kfg78NgBm4/xQD5dyKit+QTY6/bmCaO/HN4g= X-Received: by 2002:a5e:a815:: with SMTP id c21mr35696792ioa.141.1608023469036; Tue, 15 Dec 2020 01:11:09 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> From: Fabien Imbault Date: Tue, 15 Dec 2020 10:10:56 +0100 Message-ID: To: Torsten Lodderstedt Cc: Stephen Moore , txauth gnap , Justin Richer , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000a9990705b67d238c" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 09:11:13 -0000 --000000000000a9990705b67d238c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, You're right on both accounts. - for the first remark, it fits quite nicely the init request / continuation pattern - for the second remark, it is a sort of handle for the continuation request, which will eventually lead to the issuance or refresh of standard access tokens Having a specific name is a possibility, I actually suggested that too at some point. Fabien On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt wrote: > Hi Fabien, > > > Am 12.12.2020 um 12:06 schrieb Fabien Imbault >: > > > > Hi, > > > > On the contrary your feedback is most welcome. > > > > It doesn't accept any token, it needs the particular token as described > in 3.1 and which is not a bearer token (that's what the "key" : true > parameter is supposed to convey). > > > > Let us know if you need more clarifications. > > Thanks for the clarification. I think only accepting this kind of token a= t > the continuation is a good idea otherwise the AS would need to be able to > parse and understand all sorts of access tokens. > > Conceptually, I like the idea to treat the continuation as another kind o= f > resource. However, here are some observations I want to share with you: > - This resource is different as it will issue other access tokens (of thi= s > kind) to be used in subsequent continuation requests. This requires > different handing on the client side. > - This access token (if I understand correctly) is (or at least feels > like) a handle for the underlying grant. So it is kind of the super acces= s > token to obtain other access tokens. > > I would consider using a different term to refer to this special access > token, grant token or grant handle for example, in order to prevent > confusion. > > best regards, > Torsten. > > > > > > Best > > Fabien > > > > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < > torsten@lodderstedt.net> a =C3=A9crit : > > Hi all, > > > > I didn=E2=80=99t follow GNAP closely so bear with me if me question see= ms naive. > > > > After having skimmed through the current draft and the PR, I=E2=80=98m = not sure > whether the continuation requests accepts any access token issued to the = RC > or the particular access token returned in the =E2=80=9Econtinue=E2=80=9C= element in > section 3.1.. > > > > Can you please shed some light on this? > > > > kind regards, > > Torsten. > > > >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault >: > >> > >> =EF=BB=BF > >> You're completely right. Allowing the dev to be lazy is a very good > thing in general, because it's what we know will work :-) > >> > >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a > =C3=A9crit : > >> Hi Fabien, > >> > >> For #3) Even after I typed out the hypothetical attack, that was sort > of in the back of my mind, it isn't a huge risk there. So I actually agre= e > with Dick there. Something doesn't sit right with me for the unique URL > solution, so I don't like it and came up with a hypothetical that seems > like it could be a down side. > >> > >> I still think the access token model with the signed request is the wa= y > I'd like to go, because again, it's a mechanism I'd be implementing anywa= y > to talk to any 'normal' resource. The fact is there is _something_ > representing context that has to pass back and forth here, whether that i= s > an access token (which I feel like is more flexible for extensions etc), = a > unique url, or even a cookie sent in the cookie header. So just to > re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;= ) > >> -steve > >> > >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < > fabien.imbault@gmail.com> wrote: > >> Again speaking in my own name here. > >> > >> Dick, we know you'd prefer to have a different design, but this PR > shouldn't be about that. > >> > >> Back on your 3 items : > >> > >> 1) yes we could make pre-register mandatory, but we already decided > that wouldn't be how that would work. We have a client instance that allo= ws > a more generic and flexible pattern (which BTW also allows what you want) > >> > >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever > that have the tenancy to flame conversations, I suggest we speak in less > abstract terms and ask ourselves what that means in practice for devs. > Stephen and several others (myself included) have expressed that it > wouldn't be harder to implement, it would even simplify things quite a lo= t. > If you disagree please send us a code sample to really show that point by > example, because that's really not obvious. > >> > >> 3) "If someone has the client credentials, they can impersonate the > client, and all bets are off." Are you seriously making this argument? > Because if you have a better proposal than using cryptographic keys, I'm > all hears. You make it look like there's a problem, while in reality we'r= e > only relying on the basic assumption of all modern digital communications= . > >> > >> And more importantly you never responded to the issues of how to avoid > the security pitfalls of what you proposed. > >> > >> Fabien > >> > >> > >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a > =C3=A9crit : > >> > >> > >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore > wrote: > >> But from the spec: > >> " > >> When sending a non-continuation request to the AS, the RC MUST identif= y > itself by including the client field of the request... > >> ... > >> key (object / string) : The public key of the RC to be used in this > request as described in {{request-key}}. This field is REQUIRED. > >> ... > >> " > >> So on the initial request, the key will be there. > >> > >> The client field can be an object or a string. If the client is > pre-registered, then a string could be provided instead of an object. > >> > >> > >> If you don't have the access token, then how do you differentiate > between two requests from the same web application by two different users= ? > Is the web application supposed to have different credentials for every > request? > >> > >> The AS returns a URI for manipulating the request. I would change the > spec so that each request would have a unique URI. This is the usually > RESTful pattern that the resource (the grant request) has an URI. > >> > >> > >> So in this case, the easy way out is to pass the access token to the > client, who then, as i stated before, treats the continue request as a RS > call (albeit a specialized version of the RS where the RS is the AS) OR t= o > use the unique URL, > >> but that seems open to a brute force attack by a malicious RC. (What > would be the point of that attack, I don't know, I guess if someone had t= he > client credentials but not any subjects/resources they could try to > intercept the grant via continue... I just don't feel right locking thing= s > down to unique URLs that way.) > >> > >> If someone has the client credentials, they can impersonate the client= , > and all bets are off. > >> > >> LOTS of RS servers return a resource specific URL -- my proposal is no > different. > >> > >> > >> > >> -steve > >> > >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt > wrote: > >> Hi Stephen > >> > >> The client is signing the first request. The key *might* be in the > body. The client is signing all the subsequent requests as well. The > "access token" is not needed by the client to prove it is authorized as t= he > client is proving it is the same client again. > >> > >> In other words, I don't see the need for an access token, so it does > not need to be put in a URL or an auth header. > >> > >> If a developer really, really wants to hand context back to the client > for subsequent calls, they can put it in the URL or some other method. > Putting it in the HTTP Authorization header is confusing because it is NO= T > an access token -- it is the context of the request. > >> > >> =E1=90=A7 > >> > >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore > wrote: > >> Even though I've only been lightly following things, I feel the need t= o > voice my preference as a developer since I will probably someday have to > either write a RC or RS... > >> > >> The way I see it is the RC makes the initial request to the AS as part > of this request, it provides it's key in the body... (So no use of the > Authorization header) > >> At this point that request, represented by the continue URL + "Access > Token", from my lazy developer standpoint, is a Resource Endpoint and > Access Token, and the AS is acting as a specialized RS in this case. > >> So my client posts to whatever URL with the 'access token' in the > authorization header, just like acting on any other resource I have a tok= en > for. YES, I get a new token value to use every call, and there is a > decision point of "Do I have another continue, or do I have a real token > for the resource..." But the mechanism is the same to me in the client. > >> Personally I like that, because if I have an access_token, I already > think "Put it in the auth header." > >> > >> So my vote would be +1 for the pull request at this time. > >> -steve > >> > >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt > wrote: > >> inline ... > >> > >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote: > >> Others had already responded to this previous thread, but I wanted to > add a couple points to clarify some things. > >> > >>> 3) What the client has to do with the "access token" is not the same > as access tokens for an RS. The client gets a new "access token" for each > grant request, and for each API call to the AS, and the client learns it > can not make any more API calls for that specific request when it does no= t > get an "access token" back. This is a completely different design pattern > than calling an RS API with an access token, and is a new design pattern > for calling APIs. This adds complexity to the client that it would not > normally have, and I don't think GNAP is the right place to start a new > design pattern. > >>> > >> > >> I=E2=80=99m not sure what you mean by these being different =E2=80=94 = the whole point > of the design is that the client would be doing the same thing with the > access token at the AS that it does with the RS by re-using the access > token structure. Can you please describe what the differences are, apart > from the rotation? Presentation of the token and signing of the message a= re > identical. > >> > >> The client is getting the "access token" from its API. It is not using > an "access_token" in other API calls to the AS. > >> > >> > >> Rotation of the access token and artifacts for ongoing continuation > responses is a separate issue to be discussed: > https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 > >> > >> And for what it=E2=80=99s worth, GNAP is absolutely the right place to= have new > designs =E2=80=94 not that this is one. > >> > >> You are proposing a new way for an API to provide context for > subsequent API calls. Looks out of scope to me. > >> > >> > >>> 4) Clients that only want claims from the AS and no access tokens wil= l > be required to support an API calling mechanism they would not have to > support otherwise. > >> > >> Correct, but the delta between the calls a client would make with and > without an access token is vanishingly small. The client has to sign the > initial request in some fashion, and it will sign the continuation reques= t > in the same exact fashion, but now include an access token in that reques= t. > >> > >> Per my other point, there is no value to me in my implementations of > passing context back and forth between the client and AS -- so it is extr= a > work providing no value. > >> > >> Also, any client authentication mechanism that wants to use the HTTP > Authentication header is precluded from using it. > >> > >> > >> > >> Clients making a request to an AS and not getting an access token is a > new design pattern. I think it has value and should be included, but OAut= h > today shows us the immense value of getting access tokens for calling API= s, > and so we shouldn=E2=80=99t optimize away from that pattern. > >> > >>> > >>> 5) If the AS does not provide an "access token", there is no mechanis= m > for a client to delete the request, as the client is not allowed to make = a > call without an "access token". > >> > >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D= field then the > client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99s= intentional. The AS is > telling this client instance that it can=E2=80=99t do anything else with = this > ongoing request. If the AS wants to allow the client to manage it, it wil= l > include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. > >> > >> There is nuance in that intention. A related concern is that deleting = a > request does not seem like it is a "continue" operation. > >> > >> > >>> > >>> 6) There is no standard identifier for the request. Debugging and > auditing are hampered by the client and AS having no standard way to > identifying a request. While one AS may provide a unique URL for each gra= nt > request, another AS may use a persistent "access token" to identify the > grant request, and other ASs may issue a new "access token" on each API > call, providing no persistent identifier for the request. > >> > >> Debugging and auditing this kind of thing are functions of the AS. How > is interoperability harmed by different ASs having different methods to > identify their internal data elements? The client doesn=E2=80=99t need an= y > knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for > continuing the negotiation. > >> > >> Debugging between the client and the AS was what I was referring to. > How does a client developer identify the request when communicating to th= e > AS developer. Seems complicated. > >> > >> =E1=90=A7 > >> -- > >> TXAuth mailing list > >> TXAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > >> =E1=90=A7 > >> -- > >> TXAuth mailing list > >> TXAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > >> -- > >> TXAuth mailing list > >> TXAuth@ietf.org > >> > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txau= th&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJ= YtSpI > > --000000000000a9990705b67d238c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Torsten,=C2=A0

    You're right on b= oth accounts.=C2=A0
    - for the first remark, it fits quite nicely = the init request=C2=A0 / continuation pattern=C2=A0
    - for the sec= ond remark, it is a sort of handle for the continuation=C2=A0request, which= will eventually lead to the issuance or refresh of standard access tokens= =C2=A0

    Having a specific=C2=A0name is a possibilit= y, I actually suggested that too at some point.=C2=A0

    <= div>Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wro= te:
    Hi Fabien, <= br>
    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

    --000000000000a9990705b67d238c-- From nobody Tue Dec 15 02:08:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60573A0E6B for ; Tue, 15 Dec 2020 02:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pl9vQF4ipv3 for ; Tue, 15 Dec 2020 02:08:47 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 869E73A0E63 for ; Tue, 15 Dec 2020 02:08:46 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id 6so12198567ejz.5 for ; Tue, 15 Dec 2020 02:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E3Ptd9syS0PaijI0vWq4s3fjDw84izmxEXs7F4Dd25M=; b=qliU668RXqfGq0TT3ty3/TTf+LhXG0+B7YJspiu/wMIzCEoTvXuY3rN5rURol0H70s eWOhYE95tqOr1WV0xl5xVSfnV7vtlF8wUJHZO4CvidUFU1ve7NdvgHEMxTyMHHGyyN29 dJ5o1T6ZZEBoqnWSnOn+VyUGRYMctBYCr+u+0= 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=E3Ptd9syS0PaijI0vWq4s3fjDw84izmxEXs7F4Dd25M=; b=Or8aX5Y7RUuEq+Aty+RtZBHaLnVrR9ZFSuUXG/SsNxV9TMGHTR+0+6t54yse9SMSED cjjf6GLc2i889SIqJZWSux0cmLPZNF7efIuK+2OzSZf6Zsbt2yZXZoovkgnEGz+3KXLc OE8iE5atHVeeQYs3bNCboqpzgZOBTLuNIN6yluZ1eX/J9cTQWS3iegGzSWd7RwyJeOGa ft8oTfO6kIK1KxIMTDX8gtnJz3smp5VXhsBvpwpZbu+k+pyUI38SLUqQON89dtRSMVts DfazgOj9QIimEoNIq/4mvCDvf4C5ia4sHvqo32yqUM5aN5idZ5kPP/qWyhcLm3NiINpx bd7A== X-Gm-Message-State: AOAM530Y/z/saFO/a4I3hPdIJ9F6ubWlweDNh94F50KWHC83p/YaUXPf Mnyi3Sfjboc3m5VVNE/L/lozBhQhC6B42IQHvHXE+WQBbmedztYhnWzJAKLWUjPBpi7WeKOjIAi b0Y2VYyEeIqTLUUU= X-Google-Smtp-Source: ABdhPJwHBVCWKrDfXYj/6WBn8Ql2IlDO+6b83uG+Lhb73/SBcbWFMCXwUvkbAWeOXpy+TvTZSEvAglwrP4RUUOAOWVA= X-Received: by 2002:a17:906:e18:: with SMTP id l24mr25272136eji.434.1608026924656; Tue, 15 Dec 2020 02:08:44 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: From: Dave Tonge Date: Tue, 15 Dec 2020 11:08:33 +0100 Message-ID: To: Fabien Imbault Cc: Torsten Lodderstedt , Dick Hardt , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="000000000000a2739905b67df1f4" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 10:08:51 -0000 --000000000000a2739905b67df1f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So we've established that this is a different access token, that requires different handling at the client. So keeping it could cause more confusion? As an RC, I will have to store the continue `uri` as although it could be static it could also be dynamic. Why do I need to store an access token as well. It brings me no benefit as an RC, in fact it brings more complexity. As I will now need to manage multiple types of tokens with different lifecycles: *Continuation token* - can only be used at the continue endpoint (the name of which is confusing as I can use this endpoint to revoke a grant or get metadata on the grant). - may be rotated each time it is used, or may not be - provided in the `continue` section of the response - must be sender-constrained - can't be used with the token management APIs? - can be used to identify the grant when making subsequent grants *Access token(s) to use at RS* - can only be used at the specified RS - may be sender constrained - when used at the RS, will not result in rotation >From my perspective, most use-cases will require the RC to have a persistent identifier for the grant. Why not bring this into the protocol and let the AS provide this persistent identifier (through the form of the continue uri). Using a rotating access token as a persistent identifier doesn't seem like the right choice. I see no security benefit to having the continuation access token. It doesn't matter if the continue uri leaks as it is useless without an accompanying signature, i.e. any security benefit of having an access token is already provided by having a signature. The only benefits that I can see are: - If the AS wants to be fully stateless, then you can encode more data in a token than in a uri - If the AS wants to have a static endpoint for CRUD operations on the grant - To allow the AS to identity a previous grant If we dropped the access token for the continue endpoint and rather mandated a dynamic uri this would make things conceptually easier to understand, easier for the RC to implement, easier to debug and less chance of errors when rotating tokens (i.e. race conditions could be quite likely if the AS always rotates the token) *One-off grant with no continuation or ongoing management:* RC sends signature and metadata, no `continue` response provided, therefore no grant management possible *Grant with ongoing management* RC sends signature and metadata, AS responds with a continue uri that has these purposes: - can be used by the RC to continue/update, read or revoke the grant - can be used by the RC when making a new grant to identify the previous grant As an RC the only permanent items I need to store are: - the continue uri associated with the grant - any access tokens I receive for the grant Dave On Tue, 15 Dec 2020 at 10:11, Fabien Imbault wrote: > Hi Torsten, > > You're right on both accounts. > - for the first remark, it fits quite nicely the init request / > continuation pattern > - for the second remark, it is a sort of handle for the > continuation request, which will eventually lead to the issuance or refre= sh > of standard access tokens > > Having a specific name is a possibility, I actually suggested that too at > some point. > > Fabien > > On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Fabien, >> >> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault > >: >> > >> > Hi, >> > >> > On the contrary your feedback is most welcome. >> > >> > It doesn't accept any token, it needs the particular token as describe= d >> in 3.1 and which is not a bearer token (that's what the "key" : true >> parameter is supposed to convey). >> > >> > Let us know if you need more clarifications. >> >> Thanks for the clarification. I think only accepting this kind of token >> at the continuation is a good idea otherwise the AS would need to be abl= e >> to parse and understand all sorts of access tokens. >> >> Conceptually, I like the idea to treat the continuation as another kind >> of resource. However, here are some observations I want to share with yo= u: >> - This resource is different as it will issue other access tokens (of >> this kind) to be used in subsequent continuation requests. This requires >> different handing on the client side. >> - This access token (if I understand correctly) is (or at least feels >> like) a handle for the underlying grant. So it is kind of the super acce= ss >> token to obtain other access tokens. >> >> I would consider using a different term to refer to this special access >> token, grant token or grant handle for example, in order to prevent >> confusion. >> >> best regards, >> Torsten. >> >> >> > >> > Best >> > Fabien >> > >> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >> torsten@lodderstedt.net> a =C3=A9crit : >> > Hi all, >> > >> > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive. >> > >> > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure >> whether the continuation requests accepts any access token issued to the= RC >> or the particular access token returned in the =E2=80=9Econtinue=E2=80= =9C element in >> section 3.1.. >> > >> > Can you please shed some light on this? >> > >> > kind regards, >> > Torsten. >> > >> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >> fabien.imbault@gmail.com>: >> >> >> >> =EF=BB=BF >> >> You're completely right. Allowing the dev to be lazy is a very good >> thing in general, because it's what we know will work :-) >> >> >> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >> =C3=A9crit : >> >> Hi Fabien, >> >> >> >> For #3) Even after I typed out the hypothetical attack, that was sort >> of in the back of my mind, it isn't a huge risk there. So I actually agr= ee >> with Dick there. Something doesn't sit right with me for the unique URL >> solution, so I don't like it and came up with a hypothetical that seems >> like it could be a down side. >> >> >> >> I still think the access token model with the signed request is the >> way I'd like to go, because again, it's a mechanism I'd be implementing >> anyway to talk to any 'normal' resource. The fact is there is _something= _ >> representing context that has to pass back and forth here, whether that = is >> an access token (which I feel like is more flexible for extensions etc),= a >> unique url, or even a cookie sent in the cookie header. So just to >> re-iterate, I'm a +1 on this pull request, speaking as a lazy developer = ;) >> >> -steve >> >> >> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >> fabien.imbault@gmail.com> wrote: >> >> Again speaking in my own name here. >> >> >> >> Dick, we know you'd prefer to have a different design, but this PR >> shouldn't be about that. >> >> >> >> Back on your 3 items : >> >> >> >> 1) yes we could make pre-register mandatory, but we already decided >> that wouldn't be how that would work. We have a client instance that all= ows >> a more generic and flexible pattern (which BTW also allows what you want= ) >> >> >> >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever >> that have the tenancy to flame conversations, I suggest we speak in less >> abstract terms and ask ourselves what that means in practice for devs. >> Stephen and several others (myself included) have expressed that it >> wouldn't be harder to implement, it would even simplify things quite a l= ot. >> If you disagree please send us a code sample to really show that point b= y >> example, because that's really not obvious. >> >> >> >> 3) "If someone has the client credentials, they can impersonate the >> client, and all bets are off." Are you seriously making this argument? >> Because if you have a better proposal than using cryptographic keys, I'm >> all hears. You make it look like there's a problem, while in reality we'= re >> only relying on the basic assumption of all modern digital communication= s. >> >> >> >> And more importantly you never responded to the issues of how to avoi= d >> the security pitfalls of what you proposed. >> >> >> >> Fabien >> >> >> >> >> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >> =C3=A9crit : >> >> >> >> >> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >> wrote: >> >> But from the spec: >> >> " >> >> When sending a non-continuation request to the AS, the RC MUST >> identify itself by including the client field of the request... >> >> ... >> >> key (object / string) : The public key of the RC to be used in this >> request as described in {{request-key}}. This field is REQUIRED. >> >> ... >> >> " >> >> So on the initial request, the key will be there. >> >> >> >> The client field can be an object or a string. If the client is >> pre-registered, then a string could be provided instead of an object. >> >> >> >> >> >> If you don't have the access token, then how do you differentiate >> between two requests from the same web application by two different user= s? >> Is the web application supposed to have different credentials for every >> request? >> >> >> >> The AS returns a URI for manipulating the request. I would change the >> spec so that each request would have a unique URI. This is the usually >> RESTful pattern that the resource (the grant request) has an URI. >> >> >> >> >> >> So in this case, the easy way out is to pass the access token to the >> client, who then, as i stated before, treats the continue request as a R= S >> call (albeit a specialized version of the RS where the RS is the AS) OR = to >> use the unique URL, >> >> but that seems open to a brute force attack by a malicious RC. (What >> would be the point of that attack, I don't know, I guess if someone had = the >> client credentials but not any subjects/resources they could try to >> intercept the grant via continue... I just don't feel right locking thin= gs >> down to unique URLs that way.) >> >> >> >> If someone has the client credentials, they can impersonate the >> client, and all bets are off. >> >> >> >> LOTS of RS servers return a resource specific URL -- my proposal is n= o >> different. >> >> >> >> >> >> >> >> -steve >> >> >> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >> wrote: >> >> Hi Stephen >> >> >> >> The client is signing the first request. The key *might* be in the >> body. The client is signing all the subsequent requests as well. The >> "access token" is not needed by the client to prove it is authorized as = the >> client is proving it is the same client again. >> >> >> >> In other words, I don't see the need for an access token, so it does >> not need to be put in a URL or an auth header. >> >> >> >> If a developer really, really wants to hand context back to the clien= t >> for subsequent calls, they can put it in the URL or some other method. >> Putting it in the HTTP Authorization header is confusing because it is N= OT >> an access token -- it is the context of the request. >> >> >> >> =E1=90=A7 >> >> >> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >> wrote: >> >> Even though I've only been lightly following things, I feel the need >> to voice my preference as a developer since I will probably someday have= to >> either write a RC or RS... >> >> >> >> The way I see it is the RC makes the initial request to the AS as par= t >> of this request, it provides it's key in the body... (So no use of the >> Authorization header) >> >> At this point that request, represented by the continue URL + "Access >> Token", from my lazy developer standpoint, is a Resource Endpoint and >> Access Token, and the AS is acting as a specialized RS in this case. >> >> So my client posts to whatever URL with the 'access token' in the >> authorization header, just like acting on any other resource I have a to= ken >> for. YES, I get a new token value to use every call, and there is a >> decision point of "Do I have another continue, or do I have a real token >> for the resource..." But the mechanism is the same to me in the client. >> >> Personally I like that, because if I have an access_token, I already >> think "Put it in the auth header." >> >> >> >> So my vote would be +1 for the pull request at this time. >> >> -steve >> >> >> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >> wrote: >> >> inline ... >> >> >> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer wrote= : >> >> Others had already responded to this previous thread, but I wanted to >> add a couple points to clarify some things. >> >> >> >>> 3) What the client has to do with the "access token" is not the same >> as access tokens for an RS. The client gets a new "access token" for eac= h >> grant request, and for each API call to the AS, and the client learns it >> can not make any more API calls for that specific request when it does n= ot >> get an "access token" back. This is a completely different design patter= n >> than calling an RS API with an access token, and is a new design pattern >> for calling APIs. This adds complexity to the client that it would not >> normally have, and I don't think GNAP is the right place to start a new >> design pattern. >> >>> >> >> >> >> I=E2=80=99m not sure what you mean by these being different =E2=80=94= the whole point >> of the design is that the client would be doing the same thing with the >> access token at the AS that it does with the RS by re-using the access >> token structure. Can you please describe what the differences are, apart >> from the rotation? Presentation of the token and signing of the message = are >> identical. >> >> >> >> The client is getting the "access token" from its API. It is not usin= g >> an "access_token" in other API calls to the AS. >> >> >> >> >> >> Rotation of the access token and artifacts for ongoing continuation >> responses is a separate issue to be discussed: >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >> >> >> >> And for what it=E2=80=99s worth, GNAP is absolutely the right place t= o have >> new designs =E2=80=94 not that this is one. >> >> >> >> You are proposing a new way for an API to provide context for >> subsequent API calls. Looks out of scope to me. >> >> >> >> >> >>> 4) Clients that only want claims from the AS and no access tokens >> will be required to support an API calling mechanism they would not have= to >> support otherwise. >> >> >> >> Correct, but the delta between the calls a client would make with and >> without an access token is vanishingly small. The client has to sign the >> initial request in some fashion, and it will sign the continuation reque= st >> in the same exact fashion, but now include an access token in that reque= st. >> >> >> >> Per my other point, there is no value to me in my implementations of >> passing context back and forth between the client and AS -- so it is ext= ra >> work providing no value. >> >> >> >> Also, any client authentication mechanism that wants to use the HTTP >> Authentication header is precluded from using it. >> >> >> >> >> >> >> >> Clients making a request to an AS and not getting an access token is = a >> new design pattern. I think it has value and should be included, but OAu= th >> today shows us the immense value of getting access tokens for calling AP= Is, >> and so we shouldn=E2=80=99t optimize away from that pattern. >> >> >> >>> >> >>> 5) If the AS does not provide an "access token", there is no >> mechanism for a client to delete the request, as the client is not allow= ed >> to make a call without an "access token". >> >> >> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the >> client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80=99= s intentional. The AS is >> telling this client instance that it can=E2=80=99t do anything else with= this >> ongoing request. If the AS wants to allow the client to manage it, it wi= ll >> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. >> >> >> >> There is nuance in that intention. A related concern is that deleting >> a request does not seem like it is a "continue" operation. >> >> >> >> >> >>> >> >>> 6) There is no standard identifier for the request. Debugging and >> auditing are hampered by the client and AS having no standard way to >> identifying a request. While one AS may provide a unique URL for each gr= ant >> request, another AS may use a persistent "access token" to identify the >> grant request, and other ASs may issue a new "access token" on each API >> call, providing no persistent identifier for the request. >> >> >> >> Debugging and auditing this kind of thing are functions of the AS. Ho= w >> is interoperability harmed by different ASs having different methods to >> identify their internal data elements? The client doesn=E2=80=99t need a= ny >> knowledge of the AS=E2=80=99s identifiers, it just needs to know the nex= t steps for >> continuing the negotiation. >> >> >> >> Debugging between the client and the AS was what I was referring to. >> How does a client developer identify the request when communicating to t= he >> AS developer. Seems complicated. >> >> >> >> =E1=90=A7 >> >> -- >> >> TXAuth mailing list >> >> TXAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth >> >> =E1=90=A7 >> >> -- >> >> TXAuth mailing list >> >> TXAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> >> TXAuth mailing list >> >> TXAuth@ietf.org >> >> >> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txa= uth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJ= JYtSpI >> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000a2739905b67df1f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    So we've established that this is a different access t= oken, that requires different handling at the client. So keeping it could c= ause more confusion?

    As an RC, I will have to store the cont= inue `uri` as although it could be static it could also be dynamic. Why do = I need to store an access token as well.=C2=A0It brings me no benefit as an= RC, in fact it brings more complexity. As I will now need to manage multip= le types of tokens with different lifecycles:

    Continuatio= n token=C2=A0
    =C2=A0 - can only be used at the continue endpoint (= the name of which is confusing as I can use this endpoint to revoke a grant= or get metadata on the grant).
    =C2=A0- may be rotated each time it is= used, or may not be
    =C2=A0- provided in the `continue` section of the= response
    =C2=A0- must be sender-constrained
    =C2=A0- can't be= used with the token management APIs?
    =C2=A0- can be used to identify = the grant when making subsequent grants

    Access token(s) t= o use at RS
    =C2=A0=C2=A0- can only be used at the specified= RS
    =C2=A0 - may be sender constrained
    =C2=A0 - when used at the = RS, will not result in rotation

    From my perspective, most us= e-cases will require the RC to have a persistent identifier for the grant. = Why not bring this into the protocol and let the AS provide this persistent= identifier (through the form of the continue uri). Using a rotating access= token as a persistent identifier doesn't seem like the right choice.= =C2=A0

    I see no security benefit to having the continuation = access token. It doesn't matter if the continue uri leaks as it is usel= ess without an accompanying signature, i.e. any security benefit of having = an access token is already provided by having a signature.

    =
    = The only benefits that I can see are:
    =C2=A0- If the AS wants to be fu= lly stateless, then you can encode more data in a token than in a uri
    =
    = =C2=A0- If the AS wants to have a static endpoint for CRUD operations on th= e grant
    =C2=A0- To allow the AS to identity a previous grant

    =
    If we dropped the access token for the continue endpoint and rather m= andated a dynamic uri this would make things conceptually easier to underst= and, easier for the RC to implement, easier to debug and less chance of err= ors when rotating tokens (i.e. race conditions could be quite likely if the= AS always rotates the token)

    One-off grant with no conti= nuation or ongoing management:
    RC sends signature and metadata, n= o `continue` response provided, therefore no grant management possible

    Grant with ongoing management
    RC sends signature and= metadata, AS responds with a continue uri that has these purposes:
    = =C2=A0- can be used by the RC to continue/update, read or revoke the grant<= /div>
    =C2=A0- can be used by the RC when making a new grant to identify the = previous grant

    As an RC the only permanent items I need to s= tore are:
    =C2=A0- the continue uri associated with the grant
    =C2= =A0- any access tokens I receive for the grant

    Dave

    On = Tue, 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Torsten,=C2=A0
    You're right on both accounts.=C2=A0
    - for = the first remark, it fits quite nicely the init request=C2=A0 / continuatio= n pattern=C2=A0
    - for the second remark, it is a sort of handle f= or the continuation=C2=A0request, which will eventually lead to the issuanc= e or refresh of standard access tokens=C2=A0

    Havin= g a specific=C2=A0name is a possibility, I actually suggested that too at s= ome point.=C2=A0

    Fabien

    On Tue, Dec 15, 2020= at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave = Tonge
    CTO
    3D"Moneyhub<= /div>
    Mo= neyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is= a trading style of Moneyhub Financial Technology Limited which is authoris= ed and regulated by the Financial Conduct Authority ("FCA").=C2= =A0Moneyhub Financial Technology is entered on the Financial Services Regis= ter=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/. Moneyhub=C2=A0F= inancial Technology is registered in England & Wales, company registrat= ion number=C2=A0=C2=A00= 6909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limit= ed 2019=C2=A0=C2=A9

    <= div style=3D"color:rgb(51,51,51);font-family:lato,"open sans",ari= al,sans-serif;font-size:14px;letter-spacing:normal;line-height:1.4">DISCLAIMER: This email (including any attachments) is subject to copyrig= ht, and the information in it is confidential. Use of this email or of any = information in it other than by the addressee is unauthorised and unlawful.= Whilst reasonable efforts are made to ensure that any attachments are viru= s-free, it is the recipient's sole responsibility to scan all attachmen= ts for viruses. All calls and emails to and from this company may be monito= red and recorded for legitimate purposes relating to this company's bus= iness. Any opinions expressed in this email (or in any attachments) are tho= se of the author and do not necessarily represent the opinions of Moneyhub = Financial Technology Limited or of any other group company.

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

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


    --000000000000a2739905b67df1f4-- From nobody Tue Dec 15 03:10:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190033A1039 for ; Tue, 15 Dec 2020 03:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwC2tazbmqxC for ; Tue, 15 Dec 2020 03:10:24 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1DA3A1034 for ; Tue, 15 Dec 2020 03:10:24 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id z136so20082423iof.3 for ; Tue, 15 Dec 2020 03:10: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=Kc/FIXi/GVdICALzvY0Q5WcjQK1swtU/vRZVpaO8Leg=; b=qBGxi6oMvv6H8NMUE9H69TDkxLGHvKklQWiR0UlLbxo/R2zjK/6m/GYAyicsAI2D5g ypKCg+ZFBIC84yAAGbtGi2hGHCwk3p6FWIt5yblI2HNRglI2M8oTinkmw55IXgTMgVd3 yJq9Hn2q0XCeKOEBksW6wjmYp2wgNsWQV5Iioz+gHxCiE7fUL4XF/JWL5TuW6aFBsSjO dNlOIZHPVpiVvFrPZT6yuSESzDnt9Tlw3tQY5KDMjRdJM63N5UAWfKQ3okpNf/kSDtpE qi7qDHwrtQBzSIc0oQ9XzmNu5tIGHgWqMvlEi+2F2ru3QsJMOmlSm0Y2SRxxUu1EhtcZ bDWQ== 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=Kc/FIXi/GVdICALzvY0Q5WcjQK1swtU/vRZVpaO8Leg=; b=OHV1Pa2ERh2EaNEDjtqZJuoVVAE/xSecZnCvYNqlCbu0DCHyF2WdD2XCLey8rNX6iA /cEOHP9rYKaJI59DvAERJapjv/aTlRZ3rnYqQdnhepSb2hDbdHC/sCVn82zOOYrS9OnJ YtRMKGHqiM/dC0wMRfso1vj7Nqdg+AZZeMyJGe2K26MTzYFGjgWZqyOP+8HbKln8EguG Owl6Qhi69hpMYtFi7FGr6ymCi3kkxHp2zTdidMbGtGHMue4+smyA3f2NWDIFF4m0iNlE fMotfiNNLcg9AANc1SOKfW0Du8qRP/fD+4WwBEWxPTjBDOzJTGKF9JGCEON33nLpuqT4 X/3w== X-Gm-Message-State: AOAM533ZyvgI1FeG22Ja9ACm1Fc6G2IJKXy1p7YpLmqpCt5zHHjkDy/a sUQLbhyUHydGIzBtPTox91Yz5sKbN/ECelD74uM= X-Google-Smtp-Source: ABdhPJysRERNYwDl7mOyRe7K5TCxe6xybyAjps6ixvtVvmyeUmJwE1Kk/IwvNGik3MfFN2OHP7fqBXlT8Ik9WhFd+OE= X-Received: by 2002:a6b:7a0c:: with SMTP id h12mr17318369iom.162.1608030623109; Tue, 15 Dec 2020 03:10:23 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: From: Fabien Imbault Date: Tue, 15 Dec 2020 12:10:10 +0100 Message-ID: To: Dave Tonge Cc: Torsten Lodderstedt , Dick Hardt , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="00000000000014166305b67ece37" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 11:10:28 -0000 --00000000000014166305b67ece37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we always said the access token was different, and handled as a bound token. But it doesn't mean it's more difficult for the client that already needs to be able to handle tokens anyway (bearer or not, both cases could occur). It's mostly consolidating the logic. You're anticipating a lot of issues which have no specific reason to occur, such as "can't be used with the token management APIs?". The management API is part of the same general flow. Anticipating issues with rotation is useful, but there are also many ways it can be hard to manage through a stateful approach too. And fundamentally, having everything in a common model (both for the internals of the AS and for the API calls) will help improve by a large margin what is probably the weakest point in today's infrastructure. But it's early to be definitive as to the downstream impact either way. As for a persistent identifier instead of a continuation API, and generally the end of your message, it's a totally unrelated issue to this PR, so I suggest we don't discuss that here, but in a separate issue if needed. Fabien On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge wrote= : > So we've established that this is a different access token, that requires > different handling at the client. So keeping it could cause more confusio= n? > > As an RC, I will have to store the continue `uri` as although it could be > static it could also be dynamic. Why do I need to store an access token a= s > well. It brings me no benefit as an RC, in fact it brings more complexity= . > As I will now need to manage multiple types of tokens with different > lifecycles: > > *Continuation token* > - can only be used at the continue endpoint (the name of which is > confusing as I can use this endpoint to revoke a grant or get metadata on > the grant). > - may be rotated each time it is used, or may not be > - provided in the `continue` section of the response > - must be sender-constrained > - can't be used with the token management APIs? > - can be used to identify the grant when making subsequent grants > > *Access token(s) to use at RS* > - can only be used at the specified RS > - may be sender constrained > - when used at the RS, will not result in rotation > > From my perspective, most use-cases will require the RC to have a > persistent identifier for the grant. Why not bring this into the protocol > and let the AS provide this persistent identifier (through the form of th= e > continue uri). Using a rotating access token as a persistent identifier > doesn't seem like the right choice. > > I see no security benefit to having the continuation access token. It > doesn't matter if the continue uri leaks as it is useless without an > accompanying signature, i.e. any security benefit of having an access tok= en > is already provided by having a signature. > > The only benefits that I can see are: > - If the AS wants to be fully stateless, then you can encode more data i= n > a token than in a uri > - If the AS wants to have a static endpoint for CRUD operations on the > grant > - To allow the AS to identity a previous grant > > If we dropped the access token for the continue endpoint and rather > mandated a dynamic uri this would make things conceptually easier to > understand, easier for the RC to implement, easier to debug and less chan= ce > of errors when rotating tokens (i.e. race conditions could be quite likel= y > if the AS always rotates the token) > > *One-off grant with no continuation or ongoing management:* > RC sends signature and metadata, no `continue` response provided, > therefore no grant management possible > > *Grant with ongoing management* > RC sends signature and metadata, AS responds with a continue uri that has > these purposes: > - can be used by the RC to continue/update, read or revoke the grant > - can be used by the RC when making a new grant to identify the previous > grant > > As an RC the only permanent items I need to store are: > - the continue uri associated with the grant > - any access tokens I receive for the grant > > Dave > > On Tue, 15 Dec 2020 at 10:11, Fabien Imbault > wrote: > >> Hi Torsten, >> >> You're right on both accounts. >> - for the first remark, it fits quite nicely the init request / >> continuation pattern >> - for the second remark, it is a sort of handle for the >> continuation request, which will eventually lead to the issuance or refr= esh >> of standard access tokens >> >> Having a specific name is a possibility, I actually suggested that too a= t >> some point. >> >> Fabien >> >> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi Fabien, >>> >>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>> fabien.imbault@gmail.com>: >>> > >>> > Hi, >>> > >>> > On the contrary your feedback is most welcome. >>> > >>> > It doesn't accept any token, it needs the particular token as >>> described in 3.1 and which is not a bearer token (that's what the "key"= : >>> true parameter is supposed to convey). >>> > >>> > Let us know if you need more clarifications. >>> >>> Thanks for the clarification. I think only accepting this kind of token >>> at the continuation is a good idea otherwise the AS would need to be ab= le >>> to parse and understand all sorts of access tokens. >>> >>> Conceptually, I like the idea to treat the continuation as another kind >>> of resource. However, here are some observations I want to share with y= ou: >>> - This resource is different as it will issue other access tokens (of >>> this kind) to be used in subsequent continuation requests. This require= s >>> different handing on the client side. >>> - This access token (if I understand correctly) is (or at least feels >>> like) a handle for the underlying grant. So it is kind of the super acc= ess >>> token to obtain other access tokens. >>> >>> I would consider using a different term to refer to this special access >>> token, grant token or grant handle for example, in order to prevent >>> confusion. >>> >>> best regards, >>> Torsten. >>> >>> >>> > >>> > Best >>> > Fabien >>> > >>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>> torsten@lodderstedt.net> a =C3=A9crit : >>> > Hi all, >>> > >>> > I didn=E2=80=99t follow GNAP closely so bear with me if me question s= eems >>> naive. >>> > >>> > After having skimmed through the current draft and the PR, I=E2=80=98= m not >>> sure whether the continuation requests accepts any access token issued = to >>> the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in >>> section 3.1.. >>> > >>> > Can you please shed some light on this? >>> > >>> > kind regards, >>> > Torsten. >>> > >>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>> fabien.imbault@gmail.com>: >>> >> >>> >> =EF=BB=BF >>> >> You're completely right. Allowing the dev to be lazy is a very good >>> thing in general, because it's what we know will work :-) >>> >> >>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >>> =C3=A9crit : >>> >> Hi Fabien, >>> >> >>> >> For #3) Even after I typed out the hypothetical attack, that was sor= t >>> of in the back of my mind, it isn't a huge risk there. So I actually ag= ree >>> with Dick there. Something doesn't sit right with me for the unique URL >>> solution, so I don't like it and came up with a hypothetical that seems >>> like it could be a down side. >>> >> >>> >> I still think the access token model with the signed request is the >>> way I'd like to go, because again, it's a mechanism I'd be implementing >>> anyway to talk to any 'normal' resource. The fact is there is _somethin= g_ >>> representing context that has to pass back and forth here, whether that= is >>> an access token (which I feel like is more flexible for extensions etc)= , a >>> unique url, or even a cookie sent in the cookie header. So just to >>> re-iterate, I'm a +1 on this pull request, speaking as a lazy developer= ;) >>> >> -steve >>> >> >>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>> fabien.imbault@gmail.com> wrote: >>> >> Again speaking in my own name here. >>> >> >>> >> Dick, we know you'd prefer to have a different design, but this PR >>> shouldn't be about that. >>> >> >>> >> Back on your 3 items : >>> >> >>> >> 1) yes we could make pre-register mandatory, but we already decided >>> that wouldn't be how that would work. We have a client instance that al= lows >>> a more generic and flexible pattern (which BTW also allows what you wan= t) >>> >> >>> >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever >>> that have the tenancy to flame conversations, I suggest we speak in les= s >>> abstract terms and ask ourselves what that means in practice for devs. >>> Stephen and several others (myself included) have expressed that it >>> wouldn't be harder to implement, it would even simplify things quite a = lot. >>> If you disagree please send us a code sample to really show that point = by >>> example, because that's really not obvious. >>> >> >>> >> 3) "If someone has the client credentials, they can impersonate the >>> client, and all bets are off." Are you seriously making this argument? >>> Because if you have a better proposal than using cryptographic keys, I'= m >>> all hears. You make it look like there's a problem, while in reality we= 're >>> only relying on the basic assumption of all modern digital communicatio= ns. >>> >> >>> >> And more importantly you never responded to the issues of how to >>> avoid the security pitfalls of what you proposed. >>> >> >>> >> Fabien >>> >> >>> >> >>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>> =C3=A9crit : >>> >> >>> >> >>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>> wrote: >>> >> But from the spec: >>> >> " >>> >> When sending a non-continuation request to the AS, the RC MUST >>> identify itself by including the client field of the request... >>> >> ... >>> >> key (object / string) : The public key of the RC to be used in this >>> request as described in {{request-key}}. This field is REQUIRED. >>> >> ... >>> >> " >>> >> So on the initial request, the key will be there. >>> >> >>> >> The client field can be an object or a string. If the client is >>> pre-registered, then a string could be provided instead of an object. >>> >> >>> >> >>> >> If you don't have the access token, then how do you differentiate >>> between two requests from the same web application by two different use= rs? >>> Is the web application supposed to have different credentials for every >>> request? >>> >> >>> >> The AS returns a URI for manipulating the request. I would change th= e >>> spec so that each request would have a unique URI. This is the usually >>> RESTful pattern that the resource (the grant request) has an URI. >>> >> >>> >> >>> >> So in this case, the easy way out is to pass the access token to the >>> client, who then, as i stated before, treats the continue request as a = RS >>> call (albeit a specialized version of the RS where the RS is the AS) OR= to >>> use the unique URL, >>> >> but that seems open to a brute force attack by a malicious RC. (What >>> would be the point of that attack, I don't know, I guess if someone had= the >>> client credentials but not any subjects/resources they could try to >>> intercept the grant via continue... I just don't feel right locking thi= ngs >>> down to unique URLs that way.) >>> >> >>> >> If someone has the client credentials, they can impersonate the >>> client, and all bets are off. >>> >> >>> >> LOTS of RS servers return a resource specific URL -- my proposal is >>> no different. >>> >> >>> >> >>> >> >>> >> -steve >>> >> >>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>> wrote: >>> >> Hi Stephen >>> >> >>> >> The client is signing the first request. The key *might* be in the >>> body. The client is signing all the subsequent requests as well. The >>> "access token" is not needed by the client to prove it is authorized as= the >>> client is proving it is the same client again. >>> >> >>> >> In other words, I don't see the need for an access token, so it does >>> not need to be put in a URL or an auth header. >>> >> >>> >> If a developer really, really wants to hand context back to the >>> client for subsequent calls, they can put it in the URL or some other >>> method. Putting it in the HTTP Authorization header is confusing becaus= e it >>> is NOT an access token -- it is the context of the request. >>> >> >>> >> =E1=90=A7 >>> >> >>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>> wrote: >>> >> Even though I've only been lightly following things, I feel the need >>> to voice my preference as a developer since I will probably someday hav= e to >>> either write a RC or RS... >>> >> >>> >> The way I see it is the RC makes the initial request to the AS as >>> part of this request, it provides it's key in the body... (So no use of= the >>> Authorization header) >>> >> At this point that request, represented by the continue URL + "Acces= s >>> Token", from my lazy developer standpoint, is a Resource Endpoint and >>> Access Token, and the AS is acting as a specialized RS in this case. >>> >> So my client posts to whatever URL with the 'access token' in the >>> authorization header, just like acting on any other resource I have a t= oken >>> for. YES, I get a new token value to use every call, and there is a >>> decision point of "Do I have another continue, or do I have a real toke= n >>> for the resource..." But the mechanism is the same to me in the client. >>> >> Personally I like that, because if I have an access_token, I already >>> think "Put it in the auth header." >>> >> >>> >> So my vote would be +1 for the pull request at this time. >>> >> -steve >>> >> >>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>> wrote: >>> >> inline ... >>> >> >>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>> wrote: >>> >> Others had already responded to this previous thread, but I wanted t= o >>> add a couple points to clarify some things. >>> >> >>> >>> 3) What the client has to do with the "access token" is not the sam= e >>> as access tokens for an RS. The client gets a new "access token" for ea= ch >>> grant request, and for each API call to the AS, and the client learns i= t >>> can not make any more API calls for that specific request when it does = not >>> get an "access token" back. This is a completely different design patte= rn >>> than calling an RS API with an access token, and is a new design patter= n >>> for calling APIs. This adds complexity to the client that it would not >>> normally have, and I don't think GNAP is the right place to start a new >>> design pattern. >>> >>> >>> >> >>> >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point >>> of the design is that the client would be doing the same thing with the >>> access token at the AS that it does with the RS by re-using the access >>> token structure. Can you please describe what the differences are, apar= t >>> from the rotation? Presentation of the token and signing of the message= are >>> identical. >>> >> >>> >> The client is getting the "access token" from its API. It is not >>> using an "access_token" in other API calls to the AS. >>> >> >>> >> >>> >> Rotation of the access token and artifacts for ongoing continuation >>> responses is a separate issue to be discussed: >>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>> >> >>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right place = to have >>> new designs =E2=80=94 not that this is one. >>> >> >>> >> You are proposing a new way for an API to provide context for >>> subsequent API calls. Looks out of scope to me. >>> >> >>> >> >>> >>> 4) Clients that only want claims from the AS and no access tokens >>> will be required to support an API calling mechanism they would not hav= e to >>> support otherwise. >>> >> >>> >> Correct, but the delta between the calls a client would make with an= d >>> without an access token is vanishingly small. The client has to sign th= e >>> initial request in some fashion, and it will sign the continuation requ= est >>> in the same exact fashion, but now include an access token in that requ= est. >>> >> >>> >> Per my other point, there is no value to me in my implementations of >>> passing context back and forth between the client and AS -- so it is ex= tra >>> work providing no value. >>> >> >>> >> Also, any client authentication mechanism that wants to use the HTTP >>> Authentication header is precluded from using it. >>> >> >>> >> >>> >> >>> >> Clients making a request to an AS and not getting an access token is >>> a new design pattern. I think it has value and should be included, but >>> OAuth today shows us the immense value of getting access tokens for cal= ling >>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>> >> >>> >>> >>> >>> 5) If the AS does not provide an "access token", there is no >>> mechanism for a client to delete the request, as the client is not allo= wed >>> to make a call without an "access token". >>> >> >>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then the >>> client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2=80= =99s intentional. The AS is >>> telling this client instance that it can=E2=80=99t do anything else wit= h this >>> ongoing request. If the AS wants to allow the client to manage it, it w= ill >>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field= . >>> >> >>> >> There is nuance in that intention. A related concern is that deletin= g >>> a request does not seem like it is a "continue" operation. >>> >> >>> >> >>> >>> >>> >>> 6) There is no standard identifier for the request. Debugging and >>> auditing are hampered by the client and AS having no standard way to >>> identifying a request. While one AS may provide a unique URL for each g= rant >>> request, another AS may use a persistent "access token" to identify the >>> grant request, and other ASs may issue a new "access token" on each API >>> call, providing no persistent identifier for the request. >>> >> >>> >> Debugging and auditing this kind of thing are functions of the AS. >>> How is interoperability harmed by different ASs having different method= s to >>> identify their internal data elements? The client doesn=E2=80=99t need = any >>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the ne= xt steps for >>> continuing the negotiation. >>> >> >>> >> Debugging between the client and the AS was what I was referring to. >>> How does a client developer identify the request when communicating to = the >>> AS developer. Seems complicated. >>> >> >>> >> =E1=90=A7 >>> >> -- >>> >> TXAuth mailing list >>> >> TXAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/txauth >>> >> =E1=90=A7 >>> >> -- >>> >> TXAuth mailing list >>> >> TXAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >>> >> TXAuth mailing list >>> >> TXAuth@ietf.org >>> >> >>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/tx= auth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQP= JJYtSpI >>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > --00000000000014166305b67ece37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I think we always said the access token was different, and= handled as a bound token.

    But it doesn't mean it= 9;s more difficult for the client that already needs to be able to handle t= okens anyway (bearer or not, both cases could occur). It's mostly conso= lidating the logic.

    You're anticipating a= lot of issues which have no specific reason to occur, such as "can't be used= with the token management APIs?". The management API is part of the s= ame general flow.
    Anticipating issues with rotation is useful, but th= ere are also many ways it can be hard to manage through a stateful approach= too. And fundamentally, having everything in a common model (both for the = internals of the AS and for the API calls) will help improve by a large mar= gin what is probably the weakest point in today's infrastructure. But i= t's early to be definitive as to the downstream impact either way.=C2= =A0 =C2=A0

    As for a persistent identifier instead of a= continuation API, and generally the end of your message, it's a totall= y unrelated issue to this PR, so I suggest we don't discuss that here, = but in a separate issue if needed.

    Fa= bien

     --0000000000000421e205b6815683-- From nobody Tue Dec 15 06:33:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF853A1153 for ; Tue, 15 Dec 2020 06:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwQkQHGTUyKn for ; Tue, 15 Dec 2020 06:33:29 -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 397E63A1151 for ; Tue, 15 Dec 2020 06:33:28 -0800 (PST) Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BFEXONA010547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Dec 2020 09:33:25 -0500 From: Justin Richer Message-Id: <4A8B9EDB-ABCF-4F14-B152-DEDD63A9F171@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_8EEB5960-D221-4BB6-95E6-71C2E75B495C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 15 Dec 2020 09:33:24 -0500 In-Reply-To: Cc: Fabien Imbault , Torsten Lodderstedt , Dick Hardt , txauth gnap , Steve Moore To: Dave Tonge References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 14:33:34 -0000 --Apple-Mail=_8EEB5960-D221-4BB6-95E6-71C2E75B495C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Fabien that the persistent identifier is a separate issue. = The current spec re-uses the access token for this artifact, but = that=E2=80=99s potentially brittle and could be changed out for = something else. There=E2=80=99s an issue asking for expanding on the use = cases for this functionality (which hasn=E2=80=99t been addressed by = this PR): https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = A potentially-rotating URI would be just as brittle, and so having a = single codified identifier for this artifact would be useful, but it = does assume some things about the nature of the AS. Every other use the = client has to manage the ongoing request over time doesn=E2=80=99t need = an explicit identifier. Just like with OAuth-protected APIs, the server = can determine the context not just from the URI but from the rest of the = request, including the access token itself. This is both more common and = more powerful than a strict reading of REST designs. It also follows the = HATEOS principles as the entire HTTP request is taken into account, = including the access token and signature portions.=20 I=E2=80=99ll also point out that the rotation of these credentials is = also filed as a separate issue that=E2=80=99s not being addressed right = now, so we can revisit that discussion separately: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = As for the name, we could give it a different label. We have this same = pattern of issuing a resource-specific access token alongside a URL in = the Dynamic Registration specification, both in OAuth = (https://tools.ietf.org/html/rfc7592#section-3 = ) and OpenID Connect = (https://openid.net/specs/openid-connect-registration-1_0.html#Registratio= nResponse = ). Here it=E2=80=99s called the =E2=80=9Cregistration access = token=E2=80=9D =E2=80=94 but what=E2=80=99s important there, as it is = here, is that it=E2=80=99s not a different kind of artifact that the = client now has to figure out how to use, it=E2=80=99s an access token = plain and simple. In the OAuth world this is a bearer token, since = that=E2=80=99s what OAuth 2 uses. In the GNAP world it=E2=80=99ll be a = bound token, as that=E2=80=99s what we=E2=80=99re looking to build on. = This is also related to another future discussion about responses tying = an access token to a specific API that=E2=80=99s told to the client, as = we could potentially re-use those components and concepts here as well: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 = And finally, no speculation on the complexity is needed: I implemented = this pattern several months ago during the design team discussions when = we were considering this pattern, and the code is all online for people = to see.=20 https://github.com/bspk/oauth.xyz-java/ = On the AS side, the most interesting code to this discussion is in the = TransactionEndpoint class: = https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bsp= k/oauth/xyz/authserver/endpoint/TransactionEndpoint.java = Here, you=E2=80=99ll see that on initial request, the server looks up = the client to see if it=E2=80=99s been registered, but after that, it = makes sure that the token and key are appropriate for the ongoing = request. =46rom the client side it=E2=80=99s even simpler. The = client=E2=80=99s got a small service function to manage the different = signature methods that are implemented, and all of them can take in an = optional access token:=20 = https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bsp= k/oauth/xyz/http/SigningRestTemplateService.java = The heavy lift is doing the actual signing, and you need that in order = to start the process anyway. Managing the access token as an artifact to = use at the API is completely trivial since the client already needs to = manage its own state internally to do any of this. And note that all of = this is changed from how it was before: Previously, the XYZ Protocol had = used a =E2=80=9Ctransaction handle=E2=80=9D returned by the AS that the = client would use to continue the request. However, this simple model was = limiting, and the design team adopted XAuth=E2=80=99s model of = continuation being an API. In doing so, we made it like all of the other = APIs the client is going to call: in the initial state, it doesn=E2=80=99t= have any kind of access rights, it=E2=80=99s just calling. =46rom that = initial call forward, the AS just needs to know that the token and key = match what it expects.=20 In summary, my views are: - The access token pattern has a lot of benefits, otherwise we = wouldn=E2=80=99t have an entire OAuth ecosystem based on it - Magic URIs have a lot of drawbacks which are well understood; while = they can be mitigated, they can also be avoided - Continuation is an API, and treating it like the other kinds of API = the client would call makes sense - Calling this by a special name, like =E2=80=9Cgrant access token=E2=80=9D= or =E2=80=9Ccontinuation access token=E2=80=9D is fine, but it should = function like any other access token - The heavy lift for clients is on protecting the message = cryptographically, which they need to do anyway =E2=80=94 Justin > On Dec 15, 2020, at 7:50 AM, Dave Tonge = wrote: >=20 > The persistent identifier is not a different issue, the current access = token is used to reference an existing grant = =20 >=20 > It may not be more difficult for a client to use an access token at = the AS / RS. But there is definitely an overhead on the client to manage = this separate access token.=20 >=20 >=20 >=20 > On Tue, 15 Dec 2020 at 12:10, Fabien Imbault > wrote: > I think we always said the access token was different, and handled as = a bound token. >=20 > But it doesn't mean it's more difficult for the client that already = needs to be able to handle tokens anyway (bearer or not, both cases = could occur). It's mostly consolidating the logic. >=20 > You're anticipating a lot of issues which have no specific reason to = occur, such as "can't be used with the token management APIs?". The = management API is part of the same general flow. > Anticipating issues with rotation is useful, but there are also many = ways it can be hard to manage through a stateful approach too. And = fundamentally, having everything in a common model (both for the = internals of the AS and for the API calls) will help improve by a large = margin what is probably the weakest point in today's infrastructure. But = it's early to be definitive as to the downstream impact either way. =20 >=20 > As for a persistent identifier instead of a continuation API, and = generally the end of your message, it's a totally unrelated issue to = this PR, so I suggest we don't discuss that here, but in a separate = issue if needed. >=20 > Fabien >=20 > On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge > wrote: > So we've established that this is a different access token, that = requires different handling at the client. So keeping it could cause = more confusion? >=20 > As an RC, I will have to store the continue `uri` as although it could = be static it could also be dynamic. Why do I need to store an access = token as well. It brings me no benefit as an RC, in fact it brings more = complexity. As I will now need to manage multiple types of tokens with = different lifecycles: >=20 > Continuation token=20 > - can only be used at the continue endpoint (the name of which is = confusing as I can use this endpoint to revoke a grant or get metadata = on the grant). > - may be rotated each time it is used, or may not be > - provided in the `continue` section of the response > - must be sender-constrained > - can't be used with the token management APIs? > - can be used to identify the grant when making subsequent grants >=20 > Access token(s) to use at RS > - can only be used at the specified RS > - may be sender constrained > - when used at the RS, will not result in rotation >=20 > =46rom my perspective, most use-cases will require the RC to have a = persistent identifier for the grant. Why not bring this into the = protocol and let the AS provide this persistent identifier (through the = form of the continue uri). Using a rotating access token as a persistent = identifier doesn't seem like the right choice.=20 >=20 > I see no security benefit to having the continuation access token. It = doesn't matter if the continue uri leaks as it is useless without an = accompanying signature, i.e. any security benefit of having an access = token is already provided by having a signature. >=20 > The only benefits that I can see are: > - If the AS wants to be fully stateless, then you can encode more = data in a token than in a uri > - If the AS wants to have a static endpoint for CRUD operations on = the grant > - To allow the AS to identity a previous grant >=20 > If we dropped the access token for the continue endpoint and rather = mandated a dynamic uri this would make things conceptually easier to = understand, easier for the RC to implement, easier to debug and less = chance of errors when rotating tokens (i.e. race conditions could be = quite likely if the AS always rotates the token) >=20 > One-off grant with no continuation or ongoing management: > RC sends signature and metadata, no `continue` response provided, = therefore no grant management possible >=20 > Grant with ongoing management > RC sends signature and metadata, AS responds with a continue uri that = has these purposes: > - can be used by the RC to continue/update, read or revoke the grant > - can be used by the RC when making a new grant to identify the = previous grant >=20 > As an RC the only permanent items I need to store are: > - the continue uri associated with the grant > - any access tokens I receive for the grant >=20 > Dave >=20 > On Tue, 15 Dec 2020 at 10:11, Fabien Imbault > wrote: > Hi Torsten,=20 >=20 > You're right on both accounts.=20 > - for the first remark, it fits quite nicely the init request / = continuation pattern=20 > - for the second remark, it is a sort of handle for the continuation = request, which will eventually lead to the issuance or refresh of = standard access tokens=20 >=20 > Having a specific name is a possibility, I actually suggested that too = at some point.=20 >=20 > Fabien >=20 > On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt = > wrote: > Hi Fabien,=20 >=20 > > Am 12.12.2020 um 12:06 schrieb Fabien Imbault = >: > >=20 > > Hi, > >=20 > > On the contrary your feedback is most welcome.=20 > >=20 > > It doesn't accept any token, it needs the particular token as = described in 3.1 and which is not a bearer token (that's what the "key" = : true parameter is supposed to convey).=20 > >=20 > > Let us know if you need more clarifications.=20 >=20 > Thanks for the clarification. I think only accepting this kind of = token at the continuation is a good idea otherwise the AS would need to = be able to parse and understand all sorts of access tokens. >=20 > Conceptually, I like the idea to treat the continuation as another = kind of resource. However, here are some observations I want to share = with you:=20 > - This resource is different as it will issue other access tokens (of = this kind) to be used in subsequent continuation requests. This requires = different handing on the client side. > - This access token (if I understand correctly) is (or at least feels = like) a handle for the underlying grant. So it is kind of the super = access token to obtain other access tokens.=20 >=20 > I would consider using a different term to refer to this special = access token, grant token or grant handle for example, in order to = prevent confusion.=20 >=20 > best regards, > Torsten.=20 >=20 >=20 > >=20 > > Best > > Fabien=20 > >=20 > > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt = > a =C3=A9crit = : > > Hi all, > >=20 > > I didn=E2=80=99t follow GNAP closely so bear with me if me question = seems naive. > >=20 > > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token = issued to the RC or the particular access token returned in the = =E2=80=9Econtinue=E2=80=9C element in section 3.1.. > >=20 > > Can you please shed some light on this? > >=20 > > kind regards, > > Torsten. > >=20 > >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault = >: > >>=20 > >> =EF=BB=BF > >> You're completely right. Allowing the dev to be lazy is a very good = thing in general, because it's what we know will work :-)=20 > >>=20 > >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore = > a =C3=A9crit : > >> Hi Fabien, > >>=20 > >> For #3) Even after I typed out the hypothetical attack, that was = sort of in the back of my mind, it isn't a huge risk there. So I = actually agree with Dick there. Something doesn't sit right with me for = the unique URL solution, so I don't like it and came up with a = hypothetical that seems like it could be a down side. > >>=20 > >> I still think the access token model with the signed request is the = way I'd like to go, because again, it's a mechanism I'd be implementing = anyway to talk to any 'normal' resource. The fact is there is = _something_ representing context that has to pass back and forth here, = whether that is an access token (which I feel like is more flexible for = extensions etc), a unique url, or even a cookie sent in the cookie = header. So just to re-iterate, I'm a +1 on this pull request, speaking = as a lazy developer ;) > >> -steve > >>=20 > >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault = > wrote: > >> Again speaking in my own name here.=20 > >>=20 > >> Dick, we know you'd prefer to have a different design, but this PR = shouldn't be about that.=20 > >>=20 > >> Back on your 3 items : > >>=20 > >> 1) yes we could make pre-register mandatory, but we already decided = that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what = you want)=20 > >>=20 > >> 2) instead of blame arguments of who's less = restful/HATEOAS/whatever that have the tenancy to flame conversations, I = suggest we speak in less abstract terms and ask ourselves what that = means in practice for devs. Stephen and several others (myself included) = have expressed that it wouldn't be harder to implement, it would even = simplify things quite a lot. If you disagree please send us a code = sample to really show that point by example, because that's really not = obvious.=20 > >>=20 > >> 3) "If someone has the client credentials, they can impersonate the = client, and all bets are off." Are you seriously making this argument? = Because if you have a better proposal than using cryptographic keys, I'm = all hears. You make it look like there's a problem, while in reality = we're only relying on the basic assumption of all modern digital = communications.=20 > >> =20 > >> And more importantly you never responded to the issues of how to = avoid the security pitfalls of what you proposed.=20 > >>=20 > >> Fabien=20 > >>=20 > >>=20 > >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt = > a =C3=A9crit : > >>=20 > >>=20 > >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore > wrote: > >> But from the spec: > >> " > >> When sending a non-continuation request to the AS, the RC MUST = identify itself by including the client field of the request... > >> ... > >> key (object / string) : The public key of the RC to be used in this = request as described in {{request-key}}. This field is REQUIRED.=20 > >> ... > >> " > >> So on the initial request, the key will be there.=20 > >>=20 > >> The client field can be an object or a string. If the client is = pre-registered, then a string could be provided instead of an object. > >> =20 > >>=20 > >> If you don't have the access token, then how do you differentiate = between two requests from the same web application by two different = users? Is the web application supposed to have different credentials for = every request? > >>=20 > >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the = usually RESTful pattern that the resource (the grant request) has an = URI. > >>=20 > >> =20 > >> So in this case, the easy way out is to pass the access token to = the client, who then, as i stated before, treats the continue request as = a RS call (albeit a specialized version of the RS where the RS is the = AS) OR to use the unique URL,=20 > >> but that seems open to a brute force attack by a malicious RC. = (What would be the point of that attack, I don't know, I guess if = someone had the client credentials but not any subjects/resources they = could try to intercept the grant via continue... I just don't feel right = locking things down to unique URLs that way.) > >>=20 > >> If someone has the client credentials, they can impersonate the = client, and all bets are off. > >>=20 > >> LOTS of RS servers return a resource specific URL -- my proposal is = no different. > >>=20 > >>=20 > >> =20 > >> -steve > >>=20 > >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt > wrote: > >> Hi Stephen > >>=20 > >> The client is signing the first request. The key *might* be in the = body. The client is signing all the subsequent requests as well. The = "access token" is not needed by the client to prove it is authorized as = the client is proving it is the same client again. > >>=20 > >> In other words, I don't see the need for an access token, so it = does not need to be put in a URL or an auth header. > >>=20 > >> If a developer really, really wants to hand context back to the = client for subsequent calls, they can put it in the URL or some other = method. Putting it in the HTTP Authorization header is confusing because = it is NOT an access token -- it is the context of the request. > >>=20 > >> =E1=90=A7 > >>=20 > >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore > wrote: > >> Even though I've only been lightly following things, I feel the = need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...=20 > >>=20 > >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of = the Authorization header) > >> At this point that request, represented by the continue URL + = "Access Token", from my lazy developer standpoint, is a Resource = Endpoint and Access Token, and the AS is acting as a specialized RS in = this case. > >> So my client posts to whatever URL with the 'access token' in the = authorization header, just like acting on any other resource I have a = token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real = token for the resource..." But the mechanism is the same to me in the = client. > >> Personally I like that, because if I have an access_token, I = already think "Put it in the auth header."=20 > >>=20 > >> So my vote would be +1 for the pull request at this time. > >> -steve > >>=20 > >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt > wrote: > >> inline ...=20 > >>=20 > >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer > wrote: > >> Others had already responded to this previous thread, but I wanted = to add a couple points to clarify some things. > >>=20 > >>> 3) What the client has to do with the "access token" is not the = same as access tokens for an RS. The client gets a new "access token" = for each grant request, and for each API call to the AS, and the client = learns it can not make any more API calls for that specific request when = it does not get an "access token" back. This is a completely different = design pattern than calling an RS API with an access token, and is a new = design pattern for calling APIs. This adds complexity to the client that = it would not normally have, and I don't think GNAP is the right place to = start a new design pattern. > >>>=20 > >>=20 > >> I=E2=80=99m not sure what you mean by these being different =E2=80=94= the whole point of the design is that the client would be doing the = same thing with the access token at the AS that it does with the RS by = re-using the access token structure. Can you please describe what the = differences are, apart from the rotation? Presentation of the token and = signing of the message are identical. > >>=20 > >> The client is getting the "access token" from its API. It is not = using an "access_token" in other API calls to the AS. > >> =20 > >>=20 > >> Rotation of the access token and artifacts for ongoing continuation = responses is a separate issue to be discussed: = https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 = > >>=20 > >> And for what it=E2=80=99s worth, GNAP is absolutely the right place = to have new designs =E2=80=94 not that this is one. > >>=20 > >> You are proposing a new way for an API to provide context for = subsequent API calls. Looks out of scope to me. > >> =20 > >>=20 > >>> 4) Clients that only want claims from the AS and no access tokens = will be required to support an API calling mechanism they would not have = to support otherwise.=20 > >>=20 > >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign = the initial request in some fashion, and it will sign the continuation = request in the same exact fashion, but now include an access token in = that request.=20 > >>=20 > >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is = extra work providing no value. > >>=20 > >> Also, any client authentication mechanism that wants to use the = HTTP Authentication header is precluded from using it. > >>=20 > >> =20 > >>=20 > >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, = but OAuth today shows us the immense value of getting access tokens for = calling APIs, and so we shouldn=E2=80=99t optimize away from that = pattern. > >>=20 > >>>=20 > >>> 5) If the AS does not provide an "access token", there is no = mechanism for a client to delete the request, as the client is not = allowed to make a call without an "access token". > >>=20 > >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80=9D= field then the client can=E2=80=99t delete the request =E2=80=94 and = yes, that=E2=80=99s intentional. The AS is telling this client instance = that it can=E2=80=99t do anything else with this ongoing request. If the = AS wants to allow the client to manage it, it will include the = mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D field. > >>=20 > >> There is nuance in that intention. A related concern is that = deleting a request does not seem like it is a "continue" operation. > >> =20 > >>=20 > >>>=20 > >>> 6) There is no standard identifier for the request. Debugging and = auditing are hampered by the client and AS having no standard way to = identifying a request. While one AS may provide a unique URL for each = grant request, another AS may use a persistent "access token" to = identify the grant request, and other ASs may issue a new "access token" = on each API call, providing no persistent identifier for the request. > >>=20 > >> Debugging and auditing this kind of thing are functions of the AS. = How is interoperability harmed by different ASs having different methods = to identify their internal data elements? The client doesn=E2=80=99t = need any knowledge of the AS=E2=80=99s identifiers, it just needs to = know the next steps for continuing the negotiation. > >>=20 > >> Debugging between the client and the AS was what I was referring = to. How does a client developer identify the request when communicating = to the AS developer. Seems complicated. > >> =20 > >> =E1=90=A7 > >> --=20 > >> TXAuth mailing list > >> TXAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth = > >> =E1=90=A7 > >> --=20 > >> TXAuth mailing list > >> TXAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth = > >> --=20 > >> TXAuth mailing list > >> TXAuth@ietf.org > >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txaut= h&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQPJJ= YtSpI = >=20 > --=20 > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Dave Tonge > CTO > = > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL > t: +44 (0)117 280 5120 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 >=20 >=20 > --=20 > Dave Tonge > CTO > = > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 = 6FL > t: +44 (0)117 280 5120 >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 > Moneyhub Enterprise is a trading style of Moneyhub Financial = Technology Limited which is authorised and regulated by the Financial = Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on = the Financial Services Register (FRN 809360) at = https://register.fca.org.uk/ . Moneyhub = Financial Technology is registered in England & Wales, company = registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, = Bristol, BS1 6EA.=20 >=20 > DISCLAIMER: This email (including any attachments) is subject to = copyright, and the information in it is confidential. Use of this email = or of any information in it other than by the addressee is unauthorised = and unlawful. Whilst reasonable efforts are made to ensure that any = attachments are virus-free, it is the recipient's sole responsibility to = scan all attachments for viruses. All calls and emails to and from this = company may be monitored and recorded for legitimate purposes relating = to this company's business. Any opinions expressed in this email (or in = any attachments) are those of the author and do not necessarily = represent the opinions of Moneyhub Financial Technology Limited or of = any other group company. >=20 >=20 --Apple-Mail=_8EEB5960-D221-4BB6-95E6-71C2E75B495C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with Fabien that the persistent identifier is a separate issue. = The current spec re-uses the access token for this artifact, but = that=E2=80=99s potentially brittle and could be changed out for = something else. There=E2=80=99s an issue asking for expanding on the use = cases for this functionality (which hasn=E2=80=99t been addressed by = this PR):
    On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    So we've established that this is a different access token, that req= uires different handling at the client. So keeping it could cause more conf= usion?

    As an RC, I will have to stor= e the continue `uri` as although it could be static it could also be dynami= c. Why do I need to store an access token as well.=C2=A0It brings me no ben= efit as an RC, in fact it brings more complexity. As I will now need to man= age multiple types of tokens with different lifecycles:
    Continuation token=C2=A0
    =C2=A0= - can only be used at the continue endpoint (the name of which is confusin= g as I can use this endpoint to revoke a grant or get metadata on the grant= ).
    =C2=A0- may be rotated each time it is used, or may not= be
    =C2=A0- provided in the `continue` section of the resp= onse
    =C2=A0- must be sender-constrained
    = =C2=A0- can't be used with the token management APIs?

    Access token(s) to use at RS
    =C2=A0=C2=A0- can only be used at the specified RS
    =C2=A0 - may be sender constrained
    =C2=A0 = - when used at the RS, will not result in rotation

    From my perspective, most use-cases will require the RC to h= ave a persistent identifier for the grant. Why not bring this into the prot= ocol and let the AS provide this persistent identifier (through the form of= the continue uri). Using a rotating access token as a persistent identifie= r doesn't seem like the right choice.=C2=A0

    =
    I see no security benefit to having the continuation access tok= en. It doesn't matter if the continue uri leaks as it is useless withou= t an accompanying signature, i.e. any security benefit of having an access = token is already provided by having a signature.

    The only benefits that I can see are:
    =C2=A0-= If the AS wants to be fully stateless, then you can encode more data in a = token than in a uri
    =C2=A0- If the AS wants to have a stat= ic endpoint for CRUD operations on the grant
    =C2=A0- To al= low the AS to identity a previous grant

    If we dropped the access token for the continue endpoint and rather man= dated a dynamic uri this would make things conceptually easier to understan= d, easier for the RC to implement, easier to debug and less chance of error= s when rotating tokens (i.e. race conditions could be quite likely if the A= S always rotates the token)

    One-o= ff grant with no continuation or ongoing management:
    R= C sends signature and metadata, no `continue` response provided, therefore = no grant management possible

    Gran= t with ongoing management
    RC sends signature and metad= ata, AS responds with a continue uri that has these purposes:
    =C2=A0- can be used by the RC to continue/update, read or revoke the gr= ant
    =C2=A0- can be used by the RC when making a new grant = to identify the previous grant

    As an= RC the only permanent items I need to store are:
    =C2=A0- = the continue uri associated with the grant
    =C2=A0- any acc= ess tokens I receive for the grant

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Torsten,=C2=A0

    You're right on both= accounts.=C2=A0
    - for the first remark, it fits quite nicely the= init request=C2=A0 / continuation pattern=C2=A0
    - for the second= remark, it is a sort of handle for the continuation=C2=A0request, which wi= ll eventually lead to the issuance or refresh of standard access tokens=C2= =A0

    Having a specific=C2=A0name is a possibility, = I actually suggested that too at some point.=C2=A0

    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.= net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --00000000000014166305b67ece37-- From nobody Tue Dec 15 04:50:26 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D08E3A10F0 for ; Tue, 15 Dec 2020 04:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGMFkwgyjqxb for ; Tue, 15 Dec 2020 04:50:16 -0800 (PST) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 716263A10D8 for ; Tue, 15 Dec 2020 04:50:15 -0800 (PST) Received: by mail-ej1-x62b.google.com with SMTP id g20so27533443ejb.1 for ; Tue, 15 Dec 2020 04:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mhOSVFo7kG5ULKWEJWdo2M1k5nk41bJtC5jpzmtZLG4=; b=FIOqQg/NJ1C6S4Cv7blVN717u90mtiH8wXX4R+bSpVIuGAPALCM9+aXfQLZONBx1HD MgR431nZHnb7STHoNnTBMJxxpIeDEQ9k1COJ5MOQQN2z8XdyOm55dAx/bwNp8Ri7t7Nl 4I8Lgsjc6zYf0ouN6IywGd9yu8eDGwiyPuq/Y= 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=mhOSVFo7kG5ULKWEJWdo2M1k5nk41bJtC5jpzmtZLG4=; b=azta7elqRhaJ+r3s2SweXNgaH+9XSttCnh5gOjXDU/NGKWe+2xBzTlWzhP/RRXylpJ 2cenWZSfxQDnQctmNO4t2wm7R7e7lvWfF5ZFdBi5mL6shvWfN8uxSVNpcgdKloB83iGM UNX7i6fxCRj3jbbFwML1CAA/xrNktj8nalrnI5VHF5bi/blpUmqKdulNEuRGPOWUAjVK AStIO6j5lEYi/POlpjB4Ei63GDcL4kTzRhm9IjqWTeDzvtmMpD+JujeOYz+rcwEJNK4u MP6reZ4/tZDX5jqec2rmNm2QgLtAP4o4uPmNvawKU0As16ujE4JNQLQp81SfUgS+IxF2 l7NA== X-Gm-Message-State: AOAM533/CqMDbnaW6lPFj5+oaq8xPXscPRzBnhqxalcANrSwHOtpWNM0 Zo8vv3KsLlP2m6Ype+GcDjmVIB1v9bcDyl2r+HYcencVu3xWnUuCCD594yAaZG4b77BRBMtdBVy TeHIltAsOkxxPLBE= X-Google-Smtp-Source: ABdhPJzvNoahshdXn1JNSsgBqlz/hRwa51BUAwWCPkuSAcd3OWQL5sV4TnH2nGMGYvl+GwM7LZOVVBYbD332nb/vqIU= X-Received: by 2002:a17:906:cec3:: with SMTP id si3mr5564886ejb.277.1608036613549; Tue, 15 Dec 2020 04:50:13 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: From: Dave Tonge Date: Tue, 15 Dec 2020 13:50:02 +0100 Message-ID: To: Fabien Imbault Cc: Torsten Lodderstedt , Dick Hardt , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="000000000000230e8505b680332b" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 12:50:25 -0000 --000000000000230e8505b680332b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The persistent identifier is not a different issue, the current access token is used to reference an existing grant It may not be more difficult for a client to *use* an access token at the AS / RS. But there is definitely an overhead on the client to *manage* this separate access token. On Tue, 15 Dec 2020 at 12:10, Fabien Imbault wrote: > I think we always said the access token was different, and handled as a > bound token. > > But it doesn't mean it's more difficult for the client that already needs > to be able to handle tokens anyway (bearer or not, both cases could occur= ). > It's mostly consolidating the logic. > > You're anticipating a lot of issues which have no specific reason to > occur, such as "can't be used with the token management APIs?". The > management API is part of the same general flow. > Anticipating issues with rotation is useful, but there are also many ways > it can be hard to manage through a stateful approach too. And > fundamentally, having everything in a common model (both for the internal= s > of the AS and for the API calls) will help improve by a large margin what > is probably the weakest point in today's infrastructure. But it's early t= o > be definitive as to the downstream impact either way. > > As for a persistent identifier instead of a continuation API, and > generally the end of your message, it's a totally unrelated issue to this > PR, so I suggest we don't discuss that here, but in a separate issue if > needed. > > Fabien > > On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge > wrote: > >> So we've established that this is a different access token, that require= s >> different handling at the client. So keeping it could cause more confusi= on? >> >> As an RC, I will have to store the continue `uri` as although it could b= e >> static it could also be dynamic. Why do I need to store an access token = as >> well. It brings me no benefit as an RC, in fact it brings more complexit= y. >> As I will now need to manage multiple types of tokens with different >> lifecycles: >> >> *Continuation token* >> - can only be used at the continue endpoint (the name of which is >> confusing as I can use this endpoint to revoke a grant or get metadata o= n >> the grant). >> - may be rotated each time it is used, or may not be >> - provided in the `continue` section of the response >> - must be sender-constrained >> - can't be used with the token management APIs? >> - can be used to identify the grant when making subsequent grants >> >> *Access token(s) to use at RS* >> - can only be used at the specified RS >> - may be sender constrained >> - when used at the RS, will not result in rotation >> >> From my perspective, most use-cases will require the RC to have a >> persistent identifier for the grant. Why not bring this into the protoco= l >> and let the AS provide this persistent identifier (through the form of t= he >> continue uri). Using a rotating access token as a persistent identifier >> doesn't seem like the right choice. >> >> I see no security benefit to having the continuation access token. It >> doesn't matter if the continue uri leaks as it is useless without an >> accompanying signature, i.e. any security benefit of having an access to= ken >> is already provided by having a signature. >> >> The only benefits that I can see are: >> - If the AS wants to be fully stateless, then you can encode more data >> in a token than in a uri >> - If the AS wants to have a static endpoint for CRUD operations on the >> grant >> - To allow the AS to identity a previous grant >> >> If we dropped the access token for the continue endpoint and rather >> mandated a dynamic uri this would make things conceptually easier to >> understand, easier for the RC to implement, easier to debug and less cha= nce >> of errors when rotating tokens (i.e. race conditions could be quite like= ly >> if the AS always rotates the token) >> >> *One-off grant with no continuation or ongoing management:* >> RC sends signature and metadata, no `continue` response provided, >> therefore no grant management possible >> >> *Grant with ongoing management* >> RC sends signature and metadata, AS responds with a continue uri that ha= s >> these purposes: >> - can be used by the RC to continue/update, read or revoke the grant >> - can be used by the RC when making a new grant to identify the previou= s >> grant >> >> As an RC the only permanent items I need to store are: >> - the continue uri associated with the grant >> - any access tokens I receive for the grant >> >> Dave >> >> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >> wrote: >> >>> Hi Torsten, >>> >>> You're right on both accounts. >>> - for the first remark, it fits quite nicely the init request / >>> continuation pattern >>> - for the second remark, it is a sort of handle for the >>> continuation request, which will eventually lead to the issuance or ref= resh >>> of standard access tokens >>> >>> Having a specific name is a possibility, I actually suggested that too >>> at some point. >>> >>> Fabien >>> >>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>> Hi Fabien, >>>> >>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>> fabien.imbault@gmail.com>: >>>> > >>>> > Hi, >>>> > >>>> > On the contrary your feedback is most welcome. >>>> > >>>> > It doesn't accept any token, it needs the particular token as >>>> described in 3.1 and which is not a bearer token (that's what the "key= " : >>>> true parameter is supposed to convey). >>>> > >>>> > Let us know if you need more clarifications. >>>> >>>> Thanks for the clarification. I think only accepting this kind of toke= n >>>> at the continuation is a good idea otherwise the AS would need to be a= ble >>>> to parse and understand all sorts of access tokens. >>>> >>>> Conceptually, I like the idea to treat the continuation as another kin= d >>>> of resource. However, here are some observations I want to share with = you: >>>> - This resource is different as it will issue other access tokens (of >>>> this kind) to be used in subsequent continuation requests. This requir= es >>>> different handing on the client side. >>>> - This access token (if I understand correctly) is (or at least feels >>>> like) a handle for the underlying grant. So it is kind of the super ac= cess >>>> token to obtain other access tokens. >>>> >>>> I would consider using a different term to refer to this special acces= s >>>> token, grant token or grant handle for example, in order to prevent >>>> confusion. >>>> >>>> best regards, >>>> Torsten. >>>> >>>> >>>> > >>>> > Best >>>> > Fabien >>>> > >>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>> torsten@lodderstedt.net> a =C3=A9crit : >>>> > Hi all, >>>> > >>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me question = seems >>>> naive. >>>> > >>>> > After having skimmed through the current draft and the PR, I=E2=80= =98m not >>>> sure whether the continuation requests accepts any access token issued= to >>>> the RC or the particular access token returned in the =E2=80=9Econtinu= e=E2=80=9C element in >>>> section 3.1.. >>>> > >>>> > Can you please shed some light on this? >>>> > >>>> > kind regards, >>>> > Torsten. >>>> > >>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>> fabien.imbault@gmail.com>: >>>> >> >>>> >> =EF=BB=BF >>>> >> You're completely right. Allowing the dev to be lazy is a very good >>>> thing in general, because it's what we know will work :-) >>>> >> >>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >>>> =C3=A9crit : >>>> >> Hi Fabien, >>>> >> >>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>> sort of in the back of my mind, it isn't a huge risk there. So I actua= lly >>>> agree with Dick there. Something doesn't sit right with me for the uni= que >>>> URL solution, so I don't like it and came up with a hypothetical that = seems >>>> like it could be a down side. >>>> >> >>>> >> I still think the access token model with the signed request is the >>>> way I'd like to go, because again, it's a mechanism I'd be implementin= g >>>> anyway to talk to any 'normal' resource. The fact is there is _somethi= ng_ >>>> representing context that has to pass back and forth here, whether tha= t is >>>> an access token (which I feel like is more flexible for extensions etc= ), a >>>> unique url, or even a cookie sent in the cookie header. So just to >>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy develope= r ;) >>>> >> -steve >>>> >> >>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>> fabien.imbault@gmail.com> wrote: >>>> >> Again speaking in my own name here. >>>> >> >>>> >> Dick, we know you'd prefer to have a different design, but this PR >>>> shouldn't be about that. >>>> >> >>>> >> Back on your 3 items : >>>> >> >>>> >> 1) yes we could make pre-register mandatory, but we already decided >>>> that wouldn't be how that would work. We have a client instance that a= llows >>>> a more generic and flexible pattern (which BTW also allows what you wa= nt) >>>> >> >>>> >> 2) instead of blame arguments of who's less restful/HATEOAS/whateve= r >>>> that have the tenancy to flame conversations, I suggest we speak in le= ss >>>> abstract terms and ask ourselves what that means in practice for devs. >>>> Stephen and several others (myself included) have expressed that it >>>> wouldn't be harder to implement, it would even simplify things quite a= lot. >>>> If you disagree please send us a code sample to really show that point= by >>>> example, because that's really not obvious. >>>> >> >>>> >> 3) "If someone has the client credentials, they can impersonate the >>>> client, and all bets are off." Are you seriously making this argument? >>>> Because if you have a better proposal than using cryptographic keys, I= 'm >>>> all hears. You make it look like there's a problem, while in reality w= e're >>>> only relying on the basic assumption of all modern digital communicati= ons. >>>> >> >>>> >> And more importantly you never responded to the issues of how to >>>> avoid the security pitfalls of what you proposed. >>>> >> >>>> >> Fabien >>>> >> >>>> >> >>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>>> =C3=A9crit : >>>> >> >>>> >> >>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>> wrote: >>>> >> But from the spec: >>>> >> " >>>> >> When sending a non-continuation request to the AS, the RC MUST >>>> identify itself by including the client field of the request... >>>> >> ... >>>> >> key (object / string) : The public key of the RC to be used in this >>>> request as described in {{request-key}}. This field is REQUIRED. >>>> >> ... >>>> >> " >>>> >> So on the initial request, the key will be there. >>>> >> >>>> >> The client field can be an object or a string. If the client is >>>> pre-registered, then a string could be provided instead of an object. >>>> >> >>>> >> >>>> >> If you don't have the access token, then how do you differentiate >>>> between two requests from the same web application by two different us= ers? >>>> Is the web application supposed to have different credentials for ever= y >>>> request? >>>> >> >>>> >> The AS returns a URI for manipulating the request. I would change >>>> the spec so that each request would have a unique URI. This is the usu= ally >>>> RESTful pattern that the resource (the grant request) has an URI. >>>> >> >>>> >> >>>> >> So in this case, the easy way out is to pass the access token to th= e >>>> client, who then, as i stated before, treats the continue request as a= RS >>>> call (albeit a specialized version of the RS where the RS is the AS) O= R to >>>> use the unique URL, >>>> >> but that seems open to a brute force attack by a malicious RC. (Wha= t >>>> would be the point of that attack, I don't know, I guess if someone ha= d the >>>> client credentials but not any subjects/resources they could try to >>>> intercept the grant via continue... I just don't feel right locking th= ings >>>> down to unique URLs that way.) >>>> >> >>>> >> If someone has the client credentials, they can impersonate the >>>> client, and all bets are off. >>>> >> >>>> >> LOTS of RS servers return a resource specific URL -- my proposal is >>>> no different. >>>> >> >>>> >> >>>> >> >>>> >> -steve >>>> >> >>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>> wrote: >>>> >> Hi Stephen >>>> >> >>>> >> The client is signing the first request. The key *might* be in the >>>> body. The client is signing all the subsequent requests as well. The >>>> "access token" is not needed by the client to prove it is authorized a= s the >>>> client is proving it is the same client again. >>>> >> >>>> >> In other words, I don't see the need for an access token, so it doe= s >>>> not need to be put in a URL or an auth header. >>>> >> >>>> >> If a developer really, really wants to hand context back to the >>>> client for subsequent calls, they can put it in the URL or some other >>>> method. Putting it in the HTTP Authorization header is confusing becau= se it >>>> is NOT an access token -- it is the context of the request. >>>> >> >>>> >> =E1=90=A7 >>>> >> >>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>> wrote: >>>> >> Even though I've only been lightly following things, I feel the nee= d >>>> to voice my preference as a developer since I will probably someday ha= ve to >>>> either write a RC or RS... >>>> >> >>>> >> The way I see it is the RC makes the initial request to the AS as >>>> part of this request, it provides it's key in the body... (So no use o= f the >>>> Authorization header) >>>> >> At this point that request, represented by the continue URL + >>>> "Access Token", from my lazy developer standpoint, is a Resource Endpo= int >>>> and Access Token, and the AS is acting as a specialized RS in this cas= e. >>>> >> So my client posts to whatever URL with the 'access token' in the >>>> authorization header, just like acting on any other resource I have a = token >>>> for. YES, I get a new token value to use every call, and there is a >>>> decision point of "Do I have another continue, or do I have a real tok= en >>>> for the resource..." But the mechanism is the same to me in the client= . >>>> >> Personally I like that, because if I have an access_token, I alread= y >>>> think "Put it in the auth header." >>>> >> >>>> >> So my vote would be +1 for the pull request at this time. >>>> >> -steve >>>> >> >>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>> wrote: >>>> >> inline ... >>>> >> >>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>> wrote: >>>> >> Others had already responded to this previous thread, but I wanted >>>> to add a couple points to clarify some things. >>>> >> >>>> >>> 3) What the client has to do with the "access token" is not the >>>> same as access tokens for an RS. The client gets a new "access token" = for >>>> each grant request, and for each API call to the AS, and the client le= arns >>>> it can not make any more API calls for that specific request when it d= oes >>>> not get an "access token" back. This is a completely different design >>>> pattern than calling an RS API with an access token, and is a new desi= gn >>>> pattern for calling APIs. This adds complexity to the client that it w= ould >>>> not normally have, and I don't think GNAP is the right place to start = a new >>>> design pattern. >>>> >>> >>>> >> >>>> >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole >>>> point of the design is that the client would be doing the same thing w= ith >>>> the access token at the AS that it does with the RS by re-using the ac= cess >>>> token structure. Can you please describe what the differences are, apa= rt >>>> from the rotation? Presentation of the token and signing of the messag= e are >>>> identical. >>>> >> >>>> >> The client is getting the "access token" from its API. It is not >>>> using an "access_token" in other API calls to the AS. >>>> >> >>>> >> >>>> >> Rotation of the access token and artifacts for ongoing continuation >>>> responses is a separate issue to be discussed: >>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>> >> >>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right place= to have >>>> new designs =E2=80=94 not that this is one. >>>> >> >>>> >> You are proposing a new way for an API to provide context for >>>> subsequent API calls. Looks out of scope to me. >>>> >> >>>> >> >>>> >>> 4) Clients that only want claims from the AS and no access tokens >>>> will be required to support an API calling mechanism they would not ha= ve to >>>> support otherwise. >>>> >> >>>> >> Correct, but the delta between the calls a client would make with >>>> and without an access token is vanishingly small. The client has to si= gn >>>> the initial request in some fashion, and it will sign the continuation >>>> request in the same exact fashion, but now include an access token in = that >>>> request. >>>> >> >>>> >> Per my other point, there is no value to me in my implementations o= f >>>> passing context back and forth between the client and AS -- so it is e= xtra >>>> work providing no value. >>>> >> >>>> >> Also, any client authentication mechanism that wants to use the HTT= P >>>> Authentication header is precluded from using it. >>>> >> >>>> >> >>>> >> >>>> >> Clients making a request to an AS and not getting an access token i= s >>>> a new design pattern. I think it has value and should be included, but >>>> OAuth today shows us the immense value of getting access tokens for ca= lling >>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>> >> >>>> >>> >>>> >>> 5) If the AS does not provide an "access token", there is no >>>> mechanism for a client to delete the request, as the client is not all= owed >>>> to make a call without an "access token". >>>> >> >>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2=80= =9D field then >>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that=E2= =80=99s intentional. The AS >>>> is telling this client instance that it can=E2=80=99t do anything else= with this >>>> ongoing request. If the AS wants to allow the client to manage it, it = will >>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fiel= d. >>>> >> >>>> >> There is nuance in that intention. A related concern is that >>>> deleting a request does not seem like it is a "continue" operation. >>>> >> >>>> >> >>>> >>> >>>> >>> 6) There is no standard identifier for the request. Debugging and >>>> auditing are hampered by the client and AS having no standard way to >>>> identifying a request. While one AS may provide a unique URL for each = grant >>>> request, another AS may use a persistent "access token" to identify th= e >>>> grant request, and other ASs may issue a new "access token" on each AP= I >>>> call, providing no persistent identifier for the request. >>>> >> >>>> >> Debugging and auditing this kind of thing are functions of the AS. >>>> How is interoperability harmed by different ASs having different metho= ds to >>>> identify their internal data elements? The client doesn=E2=80=99t need= any >>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the n= ext steps for >>>> continuing the negotiation. >>>> >> >>>> >> Debugging between the client and the AS was what I was referring to= . >>>> How does a client developer identify the request when communicating to= the >>>> AS developer. Seems complicated. >>>> >> >>>> >> =E1=90=A7 >>>> >> -- >>>> >> TXAuth mailing list >>>> >> TXAuth@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>> >> =E1=90=A7 >>>> >> -- >>>> >> TXAuth mailing list >>>> >> TXAuth@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>> >> -- >>>> >> TXAuth mailing list >>>> >> TXAuth@ietf.org >>>> >> >>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/t= xauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0IQ= PJJYtSpI >>>> >>>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6= FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000230e8505b680332b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The persistent identifier=C2=A0is not a different issue, t= he current access token is used to reference a= n existing grant=C2=A0

    It may not be more difficult for = a client to use an access token at the AS / RS. But there=C2=A0is de= finitely an overhead on the client to manage=C2=A0this separate acce= ss token.=C2=A0



    On Tue, 15 Dec 2020 at 12:10, Fabi= en Imbault <fabien.imbault@gmail.com> wrote:
    I think we always said the acces= s token was different, and handled as a bound token.

    But= it doesn't mean it's more difficult for the client that already ne= eds to be able to handle tokens anyway (bearer or not, both cases could occ= ur). It's mostly consolidating the logic.

    You're anticipating a lot of issues which have no specific reason to o= ccur, such as "can't be used with the token management APIs?". The manag= ement API is part of the same general flow.
    Anticipating issues with = rotation is useful, but there are also many ways it can be hard to manage t= hrough a stateful approach too. And fundamentally, having everything in a c= ommon model (both for the internals of the AS and for the API calls) will h= elp improve by a large margin what is probably the weakest point in today&#= 39;s infrastructure. But it's early to be definitive as to the downstre= am impact either way.=C2=A0 =C2=A0

    As for a persistent= identifier instead of a continuation API, and generally the end of your me= ssage, it's a totally unrelated issue to this PR, so I suggest we don&#= 39;t discuss that here, but in a separate issue if needed.

    Fabien

    On Tue, Dec 15, 2020 at 11:08 AM Dave Ton= ge <dave.to= nge@moneyhub.com> wrote:
    So we've established that = this is a different access token, that requires different handling at the c= lient. So keeping it could cause more confusion?

    As an RC, I will have to store the continue `uri` as although = it could be static it could also be dynamic. Why do I need to store an acce= ss token as well.=C2=A0It brings me no benefit as an RC, in fact it brings = more complexity. As I will now need to manage multiple types of tokens with= different lifecycles:

    Continuati= on token=C2=A0
    =C2=A0 - can only be used at the contin= ue endpoint (the name of which is confusing as I can use this endpoint to r= evoke a grant or get metadata on the grant).
    =C2=A0- may b= e rotated each time it is used, or may not be
    =C2=A0- prov= ided in the `continue` section of the response
    =C2=A0- mus= t be sender-constrained
    =C2=A0- can't be used with the= token management APIs?
    =C2=A0- can be used to identify th= e grant when making subsequent grants

    =C2=A0=C2=A0-= can only be used at the specified RS
    =C2=A0 - may be send= er constrained
    =C2=A0 - when used at the RS, will not resu= lt in rotation

    From my perspective, = most use-cases will require the RC to have a persistent identifier for the = grant. Why not bring this into the protocol and let the AS provide this per= sistent identifier (through the form of the continue uri). Using a rotating= access token as a persistent identifier doesn't seem like the right ch= oice.=C2=A0

    I see no security bene= fit to having the continuation access token. It doesn't matter if the c= ontinue uri leaks as it is useless without an accompanying signature, i.e. = any security benefit of having an access token is already provided by havin= g a signature.

    The only benefits tha= t I can see are:
    =C2=A0- If the AS wants to be fully state= less, then you can encode more data in a token than in a uri
    =C2=A0- If the AS wants to have a static endpoint for CRUD operations on= the grant
    =C2=A0- To allow the AS to identity a previous = grant

    If we dropped the access token= for the continue endpoint and rather mandated a dynamic uri this would mak= e things conceptually easier to understand, easier for the RC to implement,= easier to debug and less chance of errors when rotating tokens (i.e. race = conditions could be quite likely if the AS always rotates the token)
    <= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif">
    One-off grant with no continuation or o= ngoing management:
    RC sends signature and metadata, no= `continue` response provided, therefore no grant management possible
    =

    Grant with ongoing management
    RC sends signature and metadata, AS responds with a continue u= ri that has these purposes:
    =C2=A0- can be used by the RC = to continue/update, read or revoke the grant
    =C2=A0- can b= e used by the RC when making a new grant to identify the previous grant

    As an RC the only permanent items I nee= d to store are:
    =C2=A0- the continue uri associated with t= he grant
    =C2=A0- any access tokens I receive for the grant=

    Dave

    On Tue, 15 Dec 2020 at 10= :11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Torsten,=C2=A0
    =
    You're right on both accounts.=C2=A0
    - for the= first remark, it fits quite nicely the init request=C2=A0 / continuation p= attern=C2=A0
    - for the second remark, it is a sort of handle for = the continuation=C2=A0request, which will eventually lead to the issuance o= r refresh of standard access tokens=C2=A0

    Having a= specific=C2=A0name is a possibility, I actually suggested that too at some= point.=C2=A0

    Fabien

    On Tue, Dec 15, 2020 at = 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --000000000000230e8505b680332b-- From nobody Tue Dec 15 04:53:25 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB953A10D4 for ; Tue, 15 Dec 2020 04:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjrYYhflvhbW for ; Tue, 15 Dec 2020 04:53:18 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13123A10DC for ; Tue, 15 Dec 2020 04:52:48 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id p187so20358487iod.4 for ; Tue, 15 Dec 2020 04:52:48 -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=qTJPNqSiLnRFPPCvDfnu8ZHO5CP/7PZ1lPJ8UyqN7t4=; b=VS6YjuN7d8nN8p7B4wq0KheE6ux/onn541iSXXi8sdnVL5bjLcPXHXSSWoSqzzb1Sv Q3Rj2kjdXuEXuVHVUD3s4XqJdTJxUbzTJXTWHsSqKPT/Zx3YldVizT1tx0I7M3JAjHR8 uxNJyLWw+6gnsIshmM/C69sMzHHv13FOtLsUjzTUjIv+spU2qpRvxPVmMz+FQvVxnBX3 vK44JAx9EiD6LHpDQR5nCRytJL2tk9+dDBb8fj6EI5oa1O2HR/yMIzeOsXWdbDPPZfi2 BwYqBPSm3k1GyxblI8m6ZHj/dGEhqy24V+UhP49d5FGL+4fbACG/fbgqVb0GC1W326VR zTjw== 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=qTJPNqSiLnRFPPCvDfnu8ZHO5CP/7PZ1lPJ8UyqN7t4=; b=KXDsOMjmRvnP8cXkFPT1DJsnT2xz9fvBD0bBqL+WoBScVi7hYc1vSXBwtjqbfDJXgV bpXNzoqghMEjgoQTTwhwIcM2+QMcEGevmllXf1vR/Zx9THbkVLqXPvOsOU65/6aJZ2eB qUx9jQpCJpD39CPCpQS1uPT9hQ3cRNnPGPi+bjQQwh0Te/RCH3J3t6IfvG7vnpm5wIzY wsu74j12kapP985TTTFKfFZvSTQGMQh6PnJ7qCMdSprF1NbDyh4/nTiOGdoea83KBOeC mYanUg5yTAWDF/nD02yXjufRo25g9o4jqSUt7+LzrXLXgIijONPGNHNeaobjaxkyiK+W ZGZQ== X-Gm-Message-State: AOAM5335yYcGcWcU+hKZ/7FWgmqRe2PyH9lSqc1AiLb4jbXu0IU3qKar POWMZggI7yRUA7rEFESC8TWPtrq0DZ65Xt7MygU= X-Google-Smtp-Source: ABdhPJw1d2lFx7OM7DdH7F7eRd3ssVxhwLdM5zxzvk8XypRviL06CLNUFHymu6cPLKRMpIl51hxY64y5lmAr4Z16QPU= X-Received: by 2002:a02:4b42:: with SMTP id q63mr8360845jaa.77.1608036766727; Tue, 15 Dec 2020 04:52:46 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: From: Fabien Imbault Date: Tue, 15 Dec 2020 13:52:33 +0100 Message-ID: To: Dave Tonge Cc: Torsten Lodderstedt , Dick Hardt , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="00000000000044442905b6803c79" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 12:53:24 -0000 --00000000000044442905b6803c79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok, could you be more specific as to what you'd expect for the persistent identifier ? Thanks Fabien On Tue, Dec 15, 2020 at 1:50 PM Dave Tonge wrote: > The persistent identifier is not a different issue, the current access > token is used to reference an existing grant > > > > It may not be more difficult for a client to *use* an access token at the > AS / RS. But there is definitely an overhead on the client to *manage* th= is > separate access token. > > > > On Tue, 15 Dec 2020 at 12:10, Fabien Imbault > wrote: > >> I think we always said the access token was different, and handled as a >> bound token. >> >> But it doesn't mean it's more difficult for the client that already need= s >> to be able to handle tokens anyway (bearer or not, both cases could occu= r). >> It's mostly consolidating the logic. >> >> You're anticipating a lot of issues which have no specific reason to >> occur, such as "can't be used with the token management APIs?". The >> management API is part of the same general flow. >> Anticipating issues with rotation is useful, but there are also many way= s >> it can be hard to manage through a stateful approach too. And >> fundamentally, having everything in a common model (both for the interna= ls >> of the AS and for the API calls) will help improve by a large margin wha= t >> is probably the weakest point in today's infrastructure. But it's early = to >> be definitive as to the downstream impact either way. >> >> As for a persistent identifier instead of a continuation API, and >> generally the end of your message, it's a totally unrelated issue to thi= s >> PR, so I suggest we don't discuss that here, but in a separate issue if >> needed. >> >> Fabien >> >> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >> wrote: >> >>> So we've established that this is a different access token, that >>> requires different handling at the client. So keeping it could cause mo= re >>> confusion? >>> >>> As an RC, I will have to store the continue `uri` as although it could >>> be static it could also be dynamic. Why do I need to store an access to= ken >>> as well. It brings me no benefit as an RC, in fact it brings more >>> complexity. As I will now need to manage multiple types of tokens with >>> different lifecycles: >>> >>> *Continuation token* >>> - can only be used at the continue endpoint (the name of which is >>> confusing as I can use this endpoint to revoke a grant or get metadata = on >>> the grant). >>> - may be rotated each time it is used, or may not be >>> - provided in the `continue` section of the response >>> - must be sender-constrained >>> - can't be used with the token management APIs? >>> - can be used to identify the grant when making subsequent grants >>> >>> *Access token(s) to use at RS* >>> - can only be used at the specified RS >>> - may be sender constrained >>> - when used at the RS, will not result in rotation >>> >>> From my perspective, most use-cases will require the RC to have a >>> persistent identifier for the grant. Why not bring this into the protoc= ol >>> and let the AS provide this persistent identifier (through the form of = the >>> continue uri). Using a rotating access token as a persistent identifier >>> doesn't seem like the right choice. >>> >>> I see no security benefit to having the continuation access token. It >>> doesn't matter if the continue uri leaks as it is useless without an >>> accompanying signature, i.e. any security benefit of having an access t= oken >>> is already provided by having a signature. >>> >>> The only benefits that I can see are: >>> - If the AS wants to be fully stateless, then you can encode more data >>> in a token than in a uri >>> - If the AS wants to have a static endpoint for CRUD operations on the >>> grant >>> - To allow the AS to identity a previous grant >>> >>> If we dropped the access token for the continue endpoint and rather >>> mandated a dynamic uri this would make things conceptually easier to >>> understand, easier for the RC to implement, easier to debug and less ch= ance >>> of errors when rotating tokens (i.e. race conditions could be quite lik= ely >>> if the AS always rotates the token) >>> >>> *One-off grant with no continuation or ongoing management:* >>> RC sends signature and metadata, no `continue` response provided, >>> therefore no grant management possible >>> >>> *Grant with ongoing management* >>> RC sends signature and metadata, AS responds with a continue uri that >>> has these purposes: >>> - can be used by the RC to continue/update, read or revoke the grant >>> - can be used by the RC when making a new grant to identify the >>> previous grant >>> >>> As an RC the only permanent items I need to store are: >>> - the continue uri associated with the grant >>> - any access tokens I receive for the grant >>> >>> Dave >>> >>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >>> wrote: >>> >>>> Hi Torsten, >>>> >>>> You're right on both accounts. >>>> - for the first remark, it fits quite nicely the init request / >>>> continuation pattern >>>> - for the second remark, it is a sort of handle for the >>>> continuation request, which will eventually lead to the issuance or re= fresh >>>> of standard access tokens >>>> >>>> Having a specific name is a possibility, I actually suggested that too >>>> at some point. >>>> >>>> Fabien >>>> >>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>>> Hi Fabien, >>>>> >>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>> fabien.imbault@gmail.com>: >>>>> > >>>>> > Hi, >>>>> > >>>>> > On the contrary your feedback is most welcome. >>>>> > >>>>> > It doesn't accept any token, it needs the particular token as >>>>> described in 3.1 and which is not a bearer token (that's what the "ke= y" : >>>>> true parameter is supposed to convey). >>>>> > >>>>> > Let us know if you need more clarifications. >>>>> >>>>> Thanks for the clarification. I think only accepting this kind of >>>>> token at the continuation is a good idea otherwise the AS would need = to be >>>>> able to parse and understand all sorts of access tokens. >>>>> >>>>> Conceptually, I like the idea to treat the continuation as another >>>>> kind of resource. However, here are some observations I want to share= with >>>>> you: >>>>> - This resource is different as it will issue other access tokens (of >>>>> this kind) to be used in subsequent continuation requests. This requi= res >>>>> different handing on the client side. >>>>> - This access token (if I understand correctly) is (or at least feels >>>>> like) a handle for the underlying grant. So it is kind of the super a= ccess >>>>> token to obtain other access tokens. >>>>> >>>>> I would consider using a different term to refer to this special >>>>> access token, grant token or grant handle for example, in order to pr= event >>>>> confusion. >>>>> >>>>> best regards, >>>>> Torsten. >>>>> >>>>> >>>>> > >>>>> > Best >>>>> > Fabien >>>>> > >>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>> > Hi all, >>>>> > >>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me question= seems >>>>> naive. >>>>> > >>>>> > After having skimmed through the current draft and the PR, I=E2=80= =98m not >>>>> sure whether the continuation requests accepts any access token issue= d to >>>>> the RC or the particular access token returned in the =E2=80=9Econtin= ue=E2=80=9C element in >>>>> section 3.1.. >>>>> > >>>>> > Can you please shed some light on this? >>>>> > >>>>> > kind regards, >>>>> > Torsten. >>>>> > >>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>> fabien.imbault@gmail.com>: >>>>> >> >>>>> >> =EF=BB=BF >>>>> >> You're completely right. Allowing the dev to be lazy is a very goo= d >>>>> thing in general, because it's what we know will work :-) >>>>> >> >>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >>>>> =C3=A9crit : >>>>> >> Hi Fabien, >>>>> >> >>>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>>> sort of in the back of my mind, it isn't a huge risk there. So I actu= ally >>>>> agree with Dick there. Something doesn't sit right with me for the un= ique >>>>> URL solution, so I don't like it and came up with a hypothetical that= seems >>>>> like it could be a down side. >>>>> >> >>>>> >> I still think the access token model with the signed request is th= e >>>>> way I'd like to go, because again, it's a mechanism I'd be implementi= ng >>>>> anyway to talk to any 'normal' resource. The fact is there is _someth= ing_ >>>>> representing context that has to pass back and forth here, whether th= at is >>>>> an access token (which I feel like is more flexible for extensions et= c), a >>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy develop= er ;) >>>>> >> -steve >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>> fabien.imbault@gmail.com> wrote: >>>>> >> Again speaking in my own name here. >>>>> >> >>>>> >> Dick, we know you'd prefer to have a different design, but this PR >>>>> shouldn't be about that. >>>>> >> >>>>> >> Back on your 3 items : >>>>> >> >>>>> >> 1) yes we could make pre-register mandatory, but we already decide= d >>>>> that wouldn't be how that would work. We have a client instance that = allows >>>>> a more generic and flexible pattern (which BTW also allows what you w= ant) >>>>> >> >>>>> >> 2) instead of blame arguments of who's less >>>>> restful/HATEOAS/whatever that have the tenancy to flame conversations= , I >>>>> suggest we speak in less abstract terms and ask ourselves what that m= eans >>>>> in practice for devs. Stephen and several others (myself included) ha= ve >>>>> expressed that it wouldn't be harder to implement, it would even simp= lify >>>>> things quite a lot. If you disagree please send us a code sample to r= eally >>>>> show that point by example, because that's really not obvious. >>>>> >> >>>>> >> 3) "If someone has the client credentials, they can impersonate th= e >>>>> client, and all bets are off." Are you seriously making this argument= ? >>>>> Because if you have a better proposal than using cryptographic keys, = I'm >>>>> all hears. You make it look like there's a problem, while in reality = we're >>>>> only relying on the basic assumption of all modern digital communicat= ions. >>>>> >> >>>>> >> And more importantly you never responded to the issues of how to >>>>> avoid the security pitfalls of what you proposed. >>>>> >> >>>>> >> Fabien >>>>> >> >>>>> >> >>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>>>> =C3=A9crit : >>>>> >> >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>> wrote: >>>>> >> But from the spec: >>>>> >> " >>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>> identify itself by including the client field of the request... >>>>> >> ... >>>>> >> key (object / string) : The public key of the RC to be used in thi= s >>>>> request as described in {{request-key}}. This field is REQUIRED. >>>>> >> ... >>>>> >> " >>>>> >> So on the initial request, the key will be there. >>>>> >> >>>>> >> The client field can be an object or a string. If the client is >>>>> pre-registered, then a string could be provided instead of an object. >>>>> >> >>>>> >> >>>>> >> If you don't have the access token, then how do you differentiate >>>>> between two requests from the same web application by two different u= sers? >>>>> Is the web application supposed to have different credentials for eve= ry >>>>> request? >>>>> >> >>>>> >> The AS returns a URI for manipulating the request. I would change >>>>> the spec so that each request would have a unique URI. This is the us= ually >>>>> RESTful pattern that the resource (the grant request) has an URI. >>>>> >> >>>>> >> >>>>> >> So in this case, the easy way out is to pass the access token to >>>>> the client, who then, as i stated before, treats the continue request= as a >>>>> RS call (albeit a specialized version of the RS where the RS is the A= S) OR >>>>> to use the unique URL, >>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>> (What would be the point of that attack, I don't know, I guess if som= eone >>>>> had the client credentials but not any subjects/resources they could = try to >>>>> intercept the grant via continue... I just don't feel right locking t= hings >>>>> down to unique URLs that way.) >>>>> >> >>>>> >> If someone has the client credentials, they can impersonate the >>>>> client, and all bets are off. >>>>> >> >>>>> >> LOTS of RS servers return a resource specific URL -- my proposal i= s >>>>> no different. >>>>> >> >>>>> >> >>>>> >> >>>>> >> -steve >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>> wrote: >>>>> >> Hi Stephen >>>>> >> >>>>> >> The client is signing the first request. The key *might* be in the >>>>> body. The client is signing all the subsequent requests as well. The >>>>> "access token" is not needed by the client to prove it is authorized = as the >>>>> client is proving it is the same client again. >>>>> >> >>>>> >> In other words, I don't see the need for an access token, so it >>>>> does not need to be put in a URL or an auth header. >>>>> >> >>>>> >> If a developer really, really wants to hand context back to the >>>>> client for subsequent calls, they can put it in the URL or some other >>>>> method. Putting it in the HTTP Authorization header is confusing beca= use it >>>>> is NOT an access token -- it is the context of the request. >>>>> >> >>>>> >> =E1=90=A7 >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>> wrote: >>>>> >> Even though I've only been lightly following things, I feel the >>>>> need to voice my preference as a developer since I will probably some= day >>>>> have to either write a RC or RS... >>>>> >> >>>>> >> The way I see it is the RC makes the initial request to the AS as >>>>> part of this request, it provides it's key in the body... (So no use = of the >>>>> Authorization header) >>>>> >> At this point that request, represented by the continue URL + >>>>> "Access Token", from my lazy developer standpoint, is a Resource Endp= oint >>>>> and Access Token, and the AS is acting as a specialized RS in this ca= se. >>>>> >> So my client posts to whatever URL with the 'access token' in the >>>>> authorization header, just like acting on any other resource I have a= token >>>>> for. YES, I get a new token value to use every call, and there is a >>>>> decision point of "Do I have another continue, or do I have a real to= ken >>>>> for the resource..." But the mechanism is the same to me in the clien= t. >>>>> >> Personally I like that, because if I have an access_token, I >>>>> already think "Put it in the auth header." >>>>> >> >>>>> >> So my vote would be +1 for the pull request at this time. >>>>> >> -steve >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>> wrote: >>>>> >> inline ... >>>>> >> >>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>> wrote: >>>>> >> Others had already responded to this previous thread, but I wanted >>>>> to add a couple points to clarify some things. >>>>> >> >>>>> >>> 3) What the client has to do with the "access token" is not the >>>>> same as access tokens for an RS. The client gets a new "access token"= for >>>>> each grant request, and for each API call to the AS, and the client l= earns >>>>> it can not make any more API calls for that specific request when it = does >>>>> not get an "access token" back. This is a completely different design >>>>> pattern than calling an RS API with an access token, and is a new des= ign >>>>> pattern for calling APIs. This adds complexity to the client that it = would >>>>> not normally have, and I don't think GNAP is the right place to start= a new >>>>> design pattern. >>>>> >>> >>>>> >> >>>>> >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole >>>>> point of the design is that the client would be doing the same thing = with >>>>> the access token at the AS that it does with the RS by re-using the a= ccess >>>>> token structure. Can you please describe what the differences are, ap= art >>>>> from the rotation? Presentation of the token and signing of the messa= ge are >>>>> identical. >>>>> >> >>>>> >> The client is getting the "access token" from its API. It is not >>>>> using an "access_token" in other API calls to the AS. >>>>> >> >>>>> >> >>>>> >> Rotation of the access token and artifacts for ongoing continuatio= n >>>>> responses is a separate issue to be discussed: >>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>> >> >>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have >>>>> new designs =E2=80=94 not that this is one. >>>>> >> >>>>> >> You are proposing a new way for an API to provide context for >>>>> subsequent API calls. Looks out of scope to me. >>>>> >> >>>>> >> >>>>> >>> 4) Clients that only want claims from the AS and no access tokens >>>>> will be required to support an API calling mechanism they would not h= ave to >>>>> support otherwise. >>>>> >> >>>>> >> Correct, but the delta between the calls a client would make with >>>>> and without an access token is vanishingly small. The client has to s= ign >>>>> the initial request in some fashion, and it will sign the continuatio= n >>>>> request in the same exact fashion, but now include an access token in= that >>>>> request. >>>>> >> >>>>> >> Per my other point, there is no value to me in my implementations >>>>> of passing context back and forth between the client and AS -- so it = is >>>>> extra work providing no value. >>>>> >> >>>>> >> Also, any client authentication mechanism that wants to use the >>>>> HTTP Authentication header is precluded from using it. >>>>> >> >>>>> >> >>>>> >> >>>>> >> Clients making a request to an AS and not getting an access token >>>>> is a new design pattern. I think it has value and should be included,= but >>>>> OAuth today shows us the immense value of getting access tokens for c= alling >>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>> >> >>>>> >>> >>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>> mechanism for a client to delete the request, as the client is not al= lowed >>>>> to make a call without an "access token". >>>>> >> >>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>> is telling this client instance that it can=E2=80=99t do anything els= e with this >>>>> ongoing request. If the AS wants to allow the client to manage it, it= will >>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fie= ld. >>>>> >> >>>>> >> There is nuance in that intention. A related concern is that >>>>> deleting a request does not seem like it is a "continue" operation. >>>>> >> >>>>> >> >>>>> >>> >>>>> >>> 6) There is no standard identifier for the request. Debugging and >>>>> auditing are hampered by the client and AS having no standard way to >>>>> identifying a request. While one AS may provide a unique URL for each= grant >>>>> request, another AS may use a persistent "access token" to identify t= he >>>>> grant request, and other ASs may issue a new "access token" on each A= PI >>>>> call, providing no persistent identifier for the request. >>>>> >> >>>>> >> Debugging and auditing this kind of thing are functions of the AS. >>>>> How is interoperability harmed by different ASs having different meth= ods to >>>>> identify their internal data elements? The client doesn=E2=80=99t nee= d any >>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the = next steps for >>>>> continuing the negotiation. >>>>> >> >>>>> >> Debugging between the client and the AS was what I was referring >>>>> to. How does a client developer identify the request when communicati= ng to >>>>> the AS developer. Seems complicated. >>>>> >> >>>>> >> =E1=90=A7 >>>>> >> -- >>>>> >> TXAuth mailing list >>>>> >> TXAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>> >> =E1=90=A7 >>>>> >> -- >>>>> >> TXAuth mailing list >>>>> >> TXAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>> >> -- >>>>> >> TXAuth mailing list >>>>> >> TXAuth@ietf.org >>>>> >> >>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/= txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0I= QPJJYtSpI >>>>> >>>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >>> -- >>> Dave Tonge >>> CTO >>> [image: Moneyhub Enterprise] >>> >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>> 6FL >>> t: +44 (0)117 280 5120 >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at *https://register.fca.org.u= k/ >>> *. Moneyhub Financial Technology is >>> registered in England & Wales, company registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS= 1 >>> 6EA. >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> > > -- > Dave Tonge > CTO > [image: Moneyhub Enterprise] > > Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6F= L > t: +44 (0)117 280 5120 > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ > *. Moneyhub Financial Technology is > registered in England & Wales, company registration number 06909772 . > Moneyhub Financial Technology Limited 2019 =C2=A9 > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > Moneyhub Enterprise is a trading style of Moneyhub Financial Technology > Limited which is authorised and regulated by the Financial Conduct > Authority ("FCA"). Moneyhub Financial Technology is entered on the > Financial Services Register (FRN 809360) at https://register.fca.org.uk/. > Moneyhub Financial Technology is registered in England & Wales, company > registration number 06909772. Moneyhub Financial Technology Limited 2020 = =C2=A9 > Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 > 6EA. > > DISCLAIMER: This email (including any attachments) is subject to > copyright, and the information in it is confidential. Use of this email o= r > of any information in it other than by the addressee is unauthorised and > unlawful. Whilst reasonable efforts are made to ensure that any attachmen= ts > are virus-free, it is the recipient's sole responsibility to scan all > attachments for viruses. All calls and emails to and from this company ma= y > be monitored and recorded for legitimate purposes relating to this > company's business. Any opinions expressed in this email (or in any > attachments) are those of the author and do not necessarily represent the > opinions of Moneyhub Financial Technology Limited or of any other group > company. > > --00000000000044442905b6803c79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ok, could you be more specific as to what you'd expect= for the persistent identifier ?
    Thanks
    Fabien
    On Tue, D= ec 15, 2020 at 1:50 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    The persistent id= entifier=C2=A0is not a different issue, the current access token is used to= reference an existing grant=C2=A0

    It may not be more difficult for a client t= o use an access token at the AS / RS. But there=C2=A0is definitely a= n overhead on the client to manage=C2=A0this separate access token.= =C2=A0



    On Tue, 15 Dec 2020= at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    I think we always= said the access token was different, and handled as a bound token.
    But it doesn't mean it's more difficult for the client = that already needs to be able to handle tokens anyway (bearer or not, both = cases could occur). It's mostly consolidating the logic.

    You're anticipating a lot of issues which have no speci= fic reason to occur, such as "can't be used with the token management APIs?&q= uot;. The management API is part of the same general flow.
    Anticipati= ng issues with rotation is useful, but there are also many ways it can be h= ard to manage through a stateful approach too. And fundamentally, having ev= erything in a common model (both for the internals of the AS and for the AP= I calls) will help improve by a large margin what is probably the weakest p= oint in today's infrastructure. But it's early to be definitive as = to the downstream impact either way.=C2=A0 =C2=A0

    As f= or a persistent identifier instead of a continuation API, and generally the= end of your message, it's a totally unrelated issue to this PR, so I s= uggest we don't discuss that here, but in a separate issue if needed.

    Fabien

    On Tue, Dec 15, 2020 at 11= :08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've = established that this is a different access token, that requires different = handling at the client. So keeping it could cause more confusion?

    As an RC, I will have to store the continue `= uri` as although it could be static it could also be dynamic. Why do I need= to store an access token as well.=C2=A0It brings me no benefit as an RC, i= n fact it brings more complexity. As I will now need to manage multiple typ= es of tokens with different lifecycles:

    Continuation token=C2=A0
    =C2=A0 - can only be u= sed at the continue endpoint (the name of which is confusing as I can use t= his endpoint to revoke a grant or get metadata on the grant).
    =C2=A0- may be rotated each time it is used, or may not be
    =C2=A0- provided in the `continue` section of the response
    =C2=A0- must be sender-constrained
    =C2=A0- can't= be used with the token management APIs?
    =C2=A0- can be us= ed to identify the grant when making subsequent grants
    Access token(s) to use at RS
    = =C2=A0=C2=A0- can only be used at the specified RS
    =C2= =A0 - may be sender constrained
    =C2=A0 - when used at the = RS, will not result in rotation

    From= my perspective, most use-cases will require the RC to have a persistent id= entifier for the grant. Why not bring this into the protocol and let the AS= provide this persistent identifier (through the form of the continue uri).= Using a rotating access token as a persistent identifier doesn't seem = like the right choice.=C2=A0

    I see n= o security benefit to having the continuation access token. It doesn't = matter if the continue uri leaks as it is useless without an accompanying s= ignature, i.e. any security benefit of having an access token is already pr= ovided by having a signature.

    The on= ly benefits that I can see are:
    =C2=A0- If the AS wants to= be fully stateless, then you can encode more data in a token than in a uri=
    =C2=A0- If the AS wants to have a static endpoint for CRU= D operations on the grant
    =C2=A0- To allow the AS to ident= ity a previous grant

    If we dropped t= he access token for the continue endpoint and rather mandated a dynamic uri= this would make things conceptually easier to understand, easier for the R= C to implement, easier to debug and less chance of errors when rotating tok= ens (i.e. race conditions could be quite likely if the AS always rotates th= e token)

    One-off grant with no co= ntinuation or ongoing management:
    RC sends signature a= nd metadata, no `continue` response provided, therefore no grant management= possible

    Grant with ongoing mana= gement
    RC sends signature and metadata, AS responds wi= th a continue uri that has these purposes:
    =C2=A0- can be = used by the RC to continue/update, read or revoke the grant

    As an RC the only perm= anent items I need to store are:
    =C2=A0- the continue uri = associated with the grant
    =C2=A0- any access tokens I rece= ive for the grant

    Dave
    On Tue, = 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Tor= sten,=C2=A0

    You're right on both accounts.=C2=A0
    - for the first remark, it fits quite nicely the init request=C2=A0 = / continuation pattern=C2=A0
    - for the second remark, it is a sor= t of handle for the continuation=C2=A0request, which will eventually lead t= o the issuance or refresh of standard access tokens=C2=A0

    Having a specific=C2=A0name is a possibility, I actually suggested = that too at some point.=C2=A0

    Fabien
    On Tue, = Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --00000000000044442905b6803c79-- From nobody Tue Dec 15 05:58:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52F93A1123 for ; Tue, 15 Dec 2020 05:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oF2QbYK_QEg for ; Tue, 15 Dec 2020 05:58:26 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED213A0905 for ; Tue, 15 Dec 2020 05:58:26 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id o6so7434834iob.10 for ; Tue, 15 Dec 2020 05:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sVZlWqX0qBWW81hAjEimkGkaBmxIlr32jD1fO3HtAQs=; b=THZfJr/Osd//qoo3FQFh3/j1Gj1yk8ugGjjFbTklccl5A7ZuXZY4WHO/eE05xsjFqR 7TOwD5dfbwlIxXB+RXl6PqnX5EvT+E8EKztvMWz4/JLM0Bl3Qlynq0oVtz4RRFSVevj8 5Sojy/dVQ+UBJQrqd30DuhtAKFSChJCU8hMvI= 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=sVZlWqX0qBWW81hAjEimkGkaBmxIlr32jD1fO3HtAQs=; b=b7x1MjXV5Uzbqa7/MHNq+JDBOcZpAcWSTvNeJ0dsRtr+DwBT8l2OoPC5yfrW4GSJb3 SfXC47qz0i9+JsnEabHXxnb/QQFkj3Njw0hp7kh2l4KS7uozfz2SJKLlT7+plk6Ae67r nKXvyWA+HU7WGCqNGMEpgHYbrRryJRrgl8/zueq9ZB8go0Kdqfk8rFuQfdH95wgxzw+r eQ8xDKN4YOk0/fgoBCthMJ0cl7wdxSZtV+GYcn5Ce1AZV7F8JHWPuJl+aYaiYt/+r3bj qvybUWH9/gXmk9KLPVaK+HmAxq0BzkP2OoLub1U6DWtInnobUdvxblgEvP2p2D+GGyyM OlmA== X-Gm-Message-State: AOAM532RLm+8ai8WO04M6UaDXGDtdPpvu/RmFOaDu3hJV9pfchvdfmIY RRvc4/yh/gESP6uSLJWZwAojGARxIJRmhVY6VntJ X-Google-Smtp-Source: ABdhPJwGy76KM1GqagkeRQ7ObaXtD3TqOBR7Zfz1xEfC66RB78tBHDdzspzshRp8NnGdxVwlz5q5aJQNt3JCyucINuE= X-Received: by 2002:a02:3541:: with SMTP id y1mr38554284jae.66.1608040705179; Tue, 15 Dec 2020 05:58:25 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: From: Warren Parad Date: Tue, 15 Dec 2020 14:58:13 +0100 Message-ID: To: Fabien Imbault Cc: Dave Tonge , Stephen Moore , Torsten Lodderstedt , txauth gnap , Justin Richer , Dick Hardt Content-Type: multipart/alternative; boundary="0000000000000464af05b68127a7" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 13:58:32 -0000 --0000000000000464af05b68127a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Beyond what we're covering here, I see at least one important service tha= t > would directly benefit from tokens, around introspection/management api > (e.g. is the token still valid?). Here there's no information lookup abou= t > a grant, we could just query a bloom filter if we get the authorization t= o > do so. I agree it's not yet included but it's perfectly feasible. I think we are so focused on the "we can do this and this and thin with it" that we aren't thinking about why we *need *it. Instead of what can be done we should be thinking about, "what can't be done without it" or even perhaps "With it we won't have to..." For instance, it's easy to construct an argument against hypothetical value it could provide in cases that don't exist yet. Equally vacuous arguments could be made for coupling to the future apis/services endpoints when necessary as well as delaying adding the session token to the spec until after it is necessary. Plus the problem is not that you control the AS URI, it's that you have > only limited trust for what's in front of that. A bound access token > ensures that your call is anthenticated with the same key as before, whil= e > the alternative doesn't. Could you say more about the potential problem here, I'm not totally following. Conceptually, I like the idea to treat the continuation as another kind of > resource. Exactly, and why not. Further just as we can return arbitrary urls in the body of a request, why not utilize the hardened REST patterns and return them in for instance a Location header. By encouraging custom responses having to reassemble future requests we are implicitly saying "We don't like any of the existing recommended patterns", and while it's totally okay to digress from them, we should have a really good reason to do so. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Tue, Dec 15, 2020 at 1:53 PM Fabien Imbault wrote: > Ok, could you be more specific as to what you'd expect for the persistent > identifier ? > Thanks > Fabien > > On Tue, Dec 15, 2020 at 1:50 PM Dave Tonge > wrote: > >> The persistent identifier is not a different issue, the current access >> token is used to reference an existing grant >> >> >> >> It may not be more difficult for a client to *use* an access token at >> the AS / RS. But there is definitely an overhead on the client to >> *manage* this separate access token. >> >> >> >> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault >> wrote: >> >>> I think we always said the access token was different, and handled as a >>> bound token. >>> >>> But it doesn't mean it's more difficult for the client that already >>> needs to be able to handle tokens anyway (bearer or not, both cases cou= ld >>> occur). It's mostly consolidating the logic. >>> >>> You're anticipating a lot of issues which have no specific reason to >>> occur, such as "can't be used with the token management APIs?". The >>> management API is part of the same general flow. >>> Anticipating issues with rotation is useful, but there are also many >>> ways it can be hard to manage through a stateful approach too. And >>> fundamentally, having everything in a common model (both for the intern= als >>> of the AS and for the API calls) will help improve by a large margin wh= at >>> is probably the weakest point in today's infrastructure. But it's early= to >>> be definitive as to the downstream impact either way. >>> >>> As for a persistent identifier instead of a continuation API, and >>> generally the end of your message, it's a totally unrelated issue to th= is >>> PR, so I suggest we don't discuss that here, but in a separate issue if >>> needed. >>> >>> Fabien >>> >>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>> wrote: >>> >>>> So we've established that this is a different access token, that >>>> requires different handling at the client. So keeping it could cause m= ore >>>> confusion? >>>> >>>> As an RC, I will have to store the continue `uri` as although it could >>>> be static it could also be dynamic. Why do I need to store an access t= oken >>>> as well. It brings me no benefit as an RC, in fact it brings more >>>> complexity. As I will now need to manage multiple types of tokens with >>>> different lifecycles: >>>> >>>> *Continuation token* >>>> - can only be used at the continue endpoint (the name of which is >>>> confusing as I can use this endpoint to revoke a grant or get metadata= on >>>> the grant). >>>> - may be rotated each time it is used, or may not be >>>> - provided in the `continue` section of the response >>>> - must be sender-constrained >>>> - can't be used with the token management APIs? >>>> - can be used to identify the grant when making subsequent grants >>>> >>>> *Access token(s) to use at RS* >>>> - can only be used at the specified RS >>>> - may be sender constrained >>>> - when used at the RS, will not result in rotation >>>> >>>> From my perspective, most use-cases will require the RC to have a >>>> persistent identifier for the grant. Why not bring this into the proto= col >>>> and let the AS provide this persistent identifier (through the form of= the >>>> continue uri). Using a rotating access token as a persistent identifie= r >>>> doesn't seem like the right choice. >>>> >>>> I see no security benefit to having the continuation access token. It >>>> doesn't matter if the continue uri leaks as it is useless without an >>>> accompanying signature, i.e. any security benefit of having an access = token >>>> is already provided by having a signature. >>>> >>>> The only benefits that I can see are: >>>> - If the AS wants to be fully stateless, then you can encode more dat= a >>>> in a token than in a uri >>>> - If the AS wants to have a static endpoint for CRUD operations on th= e >>>> grant >>>> - To allow the AS to identity a previous grant >>>> >>>> If we dropped the access token for the continue endpoint and rather >>>> mandated a dynamic uri this would make things conceptually easier to >>>> understand, easier for the RC to implement, easier to debug and less c= hance >>>> of errors when rotating tokens (i.e. race conditions could be quite li= kely >>>> if the AS always rotates the token) >>>> >>>> *One-off grant with no continuation or ongoing management:* >>>> RC sends signature and metadata, no `continue` response provided, >>>> therefore no grant management possible >>>> >>>> *Grant with ongoing management* >>>> RC sends signature and metadata, AS responds with a continue uri that >>>> has these purposes: >>>> - can be used by the RC to continue/update, read or revoke the grant >>>> - can be used by the RC when making a new grant to identify the >>>> previous grant >>>> >>>> As an RC the only permanent items I need to store are: >>>> - the continue uri associated with the grant >>>> - any access tokens I receive for the grant >>>> >>>> Dave >>>> >>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >>>> wrote: >>>> >>>>> Hi Torsten, >>>>> >>>>> You're right on both accounts. >>>>> - for the first remark, it fits quite nicely the init request / >>>>> continuation pattern >>>>> - for the second remark, it is a sort of handle for the >>>>> continuation request, which will eventually lead to the issuance or r= efresh >>>>> of standard access tokens >>>>> >>>>> Having a specific name is a possibility, I actually suggested that to= o >>>>> at some point. >>>>> >>>>> Fabien >>>>> >>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> >>>>>> Hi Fabien, >>>>>> >>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>> fabien.imbault@gmail.com>: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > On the contrary your feedback is most welcome. >>>>>> > >>>>>> > It doesn't accept any token, it needs the particular token as >>>>>> described in 3.1 and which is not a bearer token (that's what the "k= ey" : >>>>>> true parameter is supposed to convey). >>>>>> > >>>>>> > Let us know if you need more clarifications. >>>>>> >>>>>> Thanks for the clarification. I think only accepting this kind of >>>>>> token at the continuation is a good idea otherwise the AS would need= to be >>>>>> able to parse and understand all sorts of access tokens. >>>>>> >>>>>> Conceptually, I like the idea to treat the continuation as another >>>>>> kind of resource. However, here are some observations I want to shar= e with >>>>>> you: >>>>>> - This resource is different as it will issue other access tokens (o= f >>>>>> this kind) to be used in subsequent continuation requests. This requ= ires >>>>>> different handing on the client side. >>>>>> - This access token (if I understand correctly) is (or at least feel= s >>>>>> like) a handle for the underlying grant. So it is kind of the super = access >>>>>> token to obtain other access tokens. >>>>>> >>>>>> I would consider using a different term to refer to this special >>>>>> access token, grant token or grant handle for example, in order to p= revent >>>>>> confusion. >>>>>> >>>>>> best regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> > >>>>>> > Best >>>>>> > Fabien >>>>>> > >>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>> > Hi all, >>>>>> > >>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me questio= n seems >>>>>> naive. >>>>>> > >>>>>> > After having skimmed through the current draft and the PR, I=E2=80= =98m not >>>>>> sure whether the continuation requests accepts any access token issu= ed to >>>>>> the RC or the particular access token returned in the =E2=80=9Econti= nue=E2=80=9C element in >>>>>> section 3.1.. >>>>>> > >>>>>> > Can you please shed some light on this? >>>>>> > >>>>>> > kind regards, >>>>>> > Torsten. >>>>>> > >>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>> fabien.imbault@gmail.com>: >>>>>> >> >>>>>> >> =EF=BB=BF >>>>>> >> You're completely right. Allowing the dev to be lazy is a very >>>>>> good thing in general, because it's what we know will work :-) >>>>>> >> >>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >>>>>> =C3=A9crit : >>>>>> >> Hi Fabien, >>>>>> >> >>>>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>>>> sort of in the back of my mind, it isn't a huge risk there. So I act= ually >>>>>> agree with Dick there. Something doesn't sit right with me for the u= nique >>>>>> URL solution, so I don't like it and came up with a hypothetical tha= t seems >>>>>> like it could be a down side. >>>>>> >> >>>>>> >> I still think the access token model with the signed request is >>>>>> the way I'd like to go, because again, it's a mechanism I'd be imple= menting >>>>>> anyway to talk to any 'normal' resource. The fact is there is _somet= hing_ >>>>>> representing context that has to pass back and forth here, whether t= hat is >>>>>> an access token (which I feel like is more flexible for extensions e= tc), a >>>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy develo= per ;) >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >> Again speaking in my own name here. >>>>>> >> >>>>>> >> Dick, we know you'd prefer to have a different design, but this P= R >>>>>> shouldn't be about that. >>>>>> >> >>>>>> >> Back on your 3 items : >>>>>> >> >>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>> decided that wouldn't be how that would work. We have a client insta= nce >>>>>> that allows a more generic and flexible pattern (which BTW also allo= ws what >>>>>> you want) >>>>>> >> >>>>>> >> 2) instead of blame arguments of who's less >>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversation= s, I >>>>>> suggest we speak in less abstract terms and ask ourselves what that = means >>>>>> in practice for devs. Stephen and several others (myself included) h= ave >>>>>> expressed that it wouldn't be harder to implement, it would even sim= plify >>>>>> things quite a lot. If you disagree please send us a code sample to = really >>>>>> show that point by example, because that's really not obvious. >>>>>> >> >>>>>> >> 3) "If someone has the client credentials, they can impersonate >>>>>> the client, and all bets are off." Are you seriously making this arg= ument? >>>>>> Because if you have a better proposal than using cryptographic keys,= I'm >>>>>> all hears. You make it look like there's a problem, while in reality= we're >>>>>> only relying on the basic assumption of all modern digital communica= tions. >>>>>> >> >>>>>> >> And more importantly you never responded to the issues of how to >>>>>> avoid the security pitfalls of what you proposed. >>>>>> >> >>>>>> >> Fabien >>>>>> >> >>>>>> >> >>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>>>>> =C3=A9crit : >>>>>> >> >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>>> wrote: >>>>>> >> But from the spec: >>>>>> >> " >>>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>>> identify itself by including the client field of the request... >>>>>> >> ... >>>>>> >> key (object / string) : The public key of the RC to be used in >>>>>> this request as described in {{request-key}}. This field is REQUIRED= . >>>>>> >> ... >>>>>> >> " >>>>>> >> So on the initial request, the key will be there. >>>>>> >> >>>>>> >> The client field can be an object or a string. If the client is >>>>>> pre-registered, then a string could be provided instead of an object= . >>>>>> >> >>>>>> >> >>>>>> >> If you don't have the access token, then how do you differentiate >>>>>> between two requests from the same web application by two different = users? >>>>>> Is the web application supposed to have different credentials for ev= ery >>>>>> request? >>>>>> >> >>>>>> >> The AS returns a URI for manipulating the request. I would change >>>>>> the spec so that each request would have a unique URI. This is the u= sually >>>>>> RESTful pattern that the resource (the grant request) has an URI. >>>>>> >> >>>>>> >> >>>>>> >> So in this case, the easy way out is to pass the access token to >>>>>> the client, who then, as i stated before, treats the continue reques= t as a >>>>>> RS call (albeit a specialized version of the RS where the RS is the = AS) OR >>>>>> to use the unique URL, >>>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>>> (What would be the point of that attack, I don't know, I guess if so= meone >>>>>> had the client credentials but not any subjects/resources they could= try to >>>>>> intercept the grant via continue... I just don't feel right locking = things >>>>>> down to unique URLs that way.) >>>>>> >> >>>>>> >> If someone has the client credentials, they can impersonate the >>>>>> client, and all bets are off. >>>>>> >> >>>>>> >> LOTS of RS servers return a resource specific URL -- my proposal >>>>>> is no different. >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>>> wrote: >>>>>> >> Hi Stephen >>>>>> >> >>>>>> >> The client is signing the first request. The key *might* be in th= e >>>>>> body. The client is signing all the subsequent requests as well. The >>>>>> "access token" is not needed by the client to prove it is authorized= as the >>>>>> client is proving it is the same client again. >>>>>> >> >>>>>> >> In other words, I don't see the need for an access token, so it >>>>>> does not need to be put in a URL or an auth header. >>>>>> >> >>>>>> >> If a developer really, really wants to hand context back to the >>>>>> client for subsequent calls, they can put it in the URL or some othe= r >>>>>> method. Putting it in the HTTP Authorization header is confusing bec= ause it >>>>>> is NOT an access token -- it is the context of the request. >>>>>> >> >>>>>> >> =E1=90=A7 >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>>> wrote: >>>>>> >> Even though I've only been lightly following things, I feel the >>>>>> need to voice my preference as a developer since I will probably som= eday >>>>>> have to either write a RC or RS... >>>>>> >> >>>>>> >> The way I see it is the RC makes the initial request to the AS as >>>>>> part of this request, it provides it's key in the body... (So no use= of the >>>>>> Authorization header) >>>>>> >> At this point that request, represented by the continue URL + >>>>>> "Access Token", from my lazy developer standpoint, is a Resource End= point >>>>>> and Access Token, and the AS is acting as a specialized RS in this c= ase. >>>>>> >> So my client posts to whatever URL with the 'access token' in the >>>>>> authorization header, just like acting on any other resource I have = a token >>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>> decision point of "Do I have another continue, or do I have a real t= oken >>>>>> for the resource..." But the mechanism is the same to me in the clie= nt. >>>>>> >> Personally I like that, because if I have an access_token, I >>>>>> already think "Put it in the auth header." >>>>>> >> >>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>> wrote: >>>>>> >> inline ... >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>> wrote: >>>>>> >> Others had already responded to this previous thread, but I wante= d >>>>>> to add a couple points to clarify some things. >>>>>> >> >>>>>> >>> 3) What the client has to do with the "access token" is not the >>>>>> same as access tokens for an RS. The client gets a new "access token= " for >>>>>> each grant request, and for each API call to the AS, and the client = learns >>>>>> it can not make any more API calls for that specific request when it= does >>>>>> not get an "access token" back. This is a completely different desig= n >>>>>> pattern than calling an RS API with an access token, and is a new de= sign >>>>>> pattern for calling APIs. This adds complexity to the client that it= would >>>>>> not normally have, and I don't think GNAP is the right place to star= t a new >>>>>> design pattern. >>>>>> >>> >>>>>> >> >>>>>> >> I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole >>>>>> point of the design is that the client would be doing the same thing= with >>>>>> the access token at the AS that it does with the RS by re-using the = access >>>>>> token structure. Can you please describe what the differences are, a= part >>>>>> from the rotation? Presentation of the token and signing of the mess= age are >>>>>> identical. >>>>>> >> >>>>>> >> The client is getting the "access token" from its API. It is not >>>>>> using an "access_token" in other API calls to the AS. >>>>>> >> >>>>>> >> >>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>> continuation responses is a separate issue to be discussed: >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >> >>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right pla= ce to >>>>>> have new designs =E2=80=94 not that this is one. >>>>>> >> >>>>>> >> You are proposing a new way for an API to provide context for >>>>>> subsequent API calls. Looks out of scope to me. >>>>>> >> >>>>>> >> >>>>>> >>> 4) Clients that only want claims from the AS and no access token= s >>>>>> will be required to support an API calling mechanism they would not = have to >>>>>> support otherwise. >>>>>> >> >>>>>> >> Correct, but the delta between the calls a client would make with >>>>>> and without an access token is vanishingly small. The client has to = sign >>>>>> the initial request in some fashion, and it will sign the continuati= on >>>>>> request in the same exact fashion, but now include an access token i= n that >>>>>> request. >>>>>> >> >>>>>> >> Per my other point, there is no value to me in my implementations >>>>>> of passing context back and forth between the client and AS -- so it= is >>>>>> extra work providing no value. >>>>>> >> >>>>>> >> Also, any client authentication mechanism that wants to use the >>>>>> HTTP Authentication header is precluded from using it. >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> Clients making a request to an AS and not getting an access token >>>>>> is a new design pattern. I think it has value and should be included= , but >>>>>> OAuth today shows us the immense value of getting access tokens for = calling >>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>> >> >>>>>> >>> >>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>> mechanism for a client to delete the request, as the client is not a= llowed >>>>>> to make a call without an "access token". >>>>>> >> >>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>>> is telling this client instance that it can=E2=80=99t do anything el= se with this >>>>>> ongoing request. If the AS wants to allow the client to manage it, i= t will >>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fi= eld. >>>>>> >> >>>>>> >> There is nuance in that intention. A related concern is that >>>>>> deleting a request does not seem like it is a "continue" operation. >>>>>> >> >>>>>> >> >>>>>> >>> >>>>>> >>> 6) There is no standard identifier for the request. Debugging an= d >>>>>> auditing are hampered by the client and AS having no standard way to >>>>>> identifying a request. While one AS may provide a unique URL for eac= h grant >>>>>> request, another AS may use a persistent "access token" to identify = the >>>>>> grant request, and other ASs may issue a new "access token" on each = API >>>>>> call, providing no persistent identifier for the request. >>>>>> >> >>>>>> >> Debugging and auditing this kind of thing are functions of the AS= . >>>>>> How is interoperability harmed by different ASs having different met= hods to >>>>>> identify their internal data elements? The client doesn=E2=80=99t ne= ed any >>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the= next steps for >>>>>> continuing the negotiation. >>>>>> >> >>>>>> >> Debugging between the client and the AS was what I was referring >>>>>> to. How does a client developer identify the request when communicat= ing to >>>>>> the AS developer. Seems complicated. >>>>>> >> >>>>>> >> =E1=90=A7 >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >> =E1=90=A7 >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> >>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo= /txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0= IQPJJYtSpI >>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>>> -- >>>> Dave Tonge >>>> CTO >>>> [image: Moneyhub Enterprise] >>>> >>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>>> 6FL >>>> t: +44 (0)117 280 5120 >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at *https://register.fca.org.= uk/ >>>> *. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772 . >>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6= FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000000464af05b68127a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Beyond w= hat we're covering here, I see at least one important service that woul= d directly benefit from tokens, around introspection/management api (e.g. i= s the token still valid?). Here there's no information lookup about a g= rant, we could just query a bloom filter if we get the authorization to do = so. I agree it's not yet included but it's perfectly feasible.=C2= =A0
    I think we are so focused on the "we can do this = and this and thin with it" that we aren't thinking about why we need it. Instead of what can be done we should be thinking about, &quo= t;what can't be done without it" or even perhaps "With it we = won't have to..."

    For instance, it's = easy to construct an argument against hypothetical value it could provide i= n cases that don't exist yet. Equally vacuous arguments could be made f= or coupling to the future apis/services endpoints when necessary as well as= delaying adding the session token to the spec until after it is necessary.=

    Plus the problem is not that you contr= ol the AS URI, it's that you have only limited trust for what's in = front of that. A bound access token ensures that your call is anthenticated= with the same key as before, while the alternative doesn't.=C2=A0
    Could you say more about the potential problem here, I'm n= ot totally following.

    Conceptually, I like the idea to treat the continuation as= another kind of resource.=C2=A0
    Exactly, and why not. Fur= ther just as we can return arbitrary urls in the body of a request, why not= utilize the hardened REST patterns and return them in for instance a Locat= ion header. By encouraging custom responses having to reassemble future req= uests we are implicitly saying "We don't like any of the existing = recommended patterns", and while it's totally okay to digress from= them, we should have a really good reason to do so.


    <= span style=3D"border:none;display:inline-block;overflow:hidden;width:199px;= height:34px">

    Warren Parad

    Founder, = CTO

    Secure your user data and complete your authorization architecture. I= mplement=C2=A0Authress.<= /span>


    On Tue, Dec 15, 2020 at 1:53 PM Fabien Imba= ult <fabien.imbault@gmail.co= m> wrote:
    Ok, could you be more specific as to what you'd expec= t for the persistent identifier ?
    Thanks
    Fabien
    On Tue, = Dec 15, 2020 at 1:50 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    reference an existing gran= t=C2=A0

    It may not be more dif= ficult for a client to use an access token at the AS / RS. But there= =C2=A0is definitely an overhead on the client to manage=C2=A0this se= parate access token.=C2=A0



    On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote= :
    I think we always said the access token was different, and handled as a = bound token.

    But it doesn't mean it's more diffi= cult for the client that already needs to be able to handle tokens anyway (= bearer or not, both cases could occur). It's mostly consolidating the l= ogic.

    You're anticipating a lot of issues= which have no specific reason to occur, such as "can't be used with the toke= n management APIs?". The management API is part of the same general fl= ow.
    Anticipating issues with rotation is useful, but there are also m= any ways it can be hard to manage through a stateful approach too. And fund= amentally, having everything in a common model (both for the internals of t= he AS and for the API calls) will help improve by a large margin what is pr= obably the weakest point in today's infrastructure. But it's early = to be definitive as to the downstream impact either way.=C2=A0 =C2=A0

    As for a persistent identifier instead of a continuation AP= I, and generally the end of your message, it's a totally unrelated issu= e to this PR, so I suggest we don't discuss that here, but in a separat= e issue if needed.

    Fabien
    =
    On Tue= , Dec 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established that this is a different access token, that r= equires different handling at the client. So keeping it could cause more co= nfusion?

    As an RC, I will have to st= ore the continue `uri` as although it could be static it could also be dyna= mic. Why do I need to store an access token as well.=C2=A0It brings me no b= enefit as an RC, in fact it brings more complexity. As I will now need to m= anage multiple types of tokens with different lifecycles:
    Continuation token=C2=A0
    = =C2=A0 - can only be used at the continue endpoint (the name of which is co= nfusing as I can use this endpoint to revoke a grant or get metadata on the= grant).
    =C2=A0- may be rotated each time it is used, or m= ay not be
    =C2=A0- provided in the `continue` section of th= e response
    =C2=A0- must be sender-constrained
    =C2=A0- can't be used with the token management APIs?
    =C2=A0- can be used to identify the grant when making subsequent grant= s

    Access token(s) to use at RS
    =C2=A0=C2=A0- can only be used at the specified R= S
    =C2=A0 - may be sender constrained
    =C2= =A0 - when used at the RS, will not result in rotation
    From my perspective, most use-cases will require the RC = to have a persistent identifier for the grant. Why not bring this into the = protocol and let the AS provide this persistent identifier (through the for= m of the continue uri). Using a rotating access token as a persistent ident= ifier doesn't seem like the right choice.=C2=A0

    I see no security benefit to having the continuation access= token. It doesn't matter if the continue uri leaks as it is useless wi= thout an accompanying signature, i.e. any security benefit of having an acc= ess token is already provided by having a signature.

    <= /div>
    The only benefits that I can see are:
    =C2= =A0- If the AS wants to be fully stateless, then you can encode more data i= n a token than in a uri
    =C2=A0- If the AS wants to have a = static endpoint for CRUD operations on the grant
    =C2=A0- T= o allow the AS to identity a previous grant

    If we dropped the access token for the continue endpoint and rather= mandated a dynamic uri this would make things conceptually easier to under= stand, easier for the RC to implement, easier to debug and less chance of e= rrors when rotating tokens (i.e. race conditions could be quite likely if t= he AS always rotates the token)

    O= ne-off grant with no continuation or ongoing management:
    RC sends signature and metadata, no `continue` response provided, theref= ore no grant management possible

    = Grant with ongoing management
    RC sends signature and= metadata, AS responds with a continue uri that has these purposes:
    =C2=A0- can be used by the RC to continue/update, read or revoke = the grant
    =C2=A0- can be used by the RC when making a new = grant to identify the previous grant

    = =C2=A0- the continue uri associated with the grant
    =C2=A0-= any access tokens I receive for the grant

    Dave

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Hi Torsten,=C2=A0

    You're right = on both accounts.=C2=A0
    - for the first remark, it fits quite nic= ely the init request=C2=A0 / continuation pattern=C2=A0
    - for the= second remark, it is a sort of handle for the continuation=C2=A0request, w= hich will eventually lead to the issuance or refresh of standard access tok= ens=C2=A0

    Having a specific=C2=A0name is a possibi= lity, I actually suggested that too at some point.=C2=A0

    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <= torsten@lodder= stedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5t= h Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2= =A0+44 (0)117 28= 0 5120

    =
    Moneyhub Enterprise is a trading style of Moneyhub F= inancial Technology Limited which is authorised and regulated by the Financ= ial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology= is entered on the Financial Services Register=C2=A0(FRN= =C2=A0809360) at https://register.fca.= org.uk/. Moneyhub=C2=A0Financial Technology is registe= red in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5t= h Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2= =A0+44 (0)117 28= 0 5120

    =
    Moneyhub Enterprise is a trading style of Moneyhub F= inancial Technology Limited which is authorised and regulated by the Financ= ial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology= is entered on the Financial Services Register=C2=A0(FRN= =C2=A0809360) at https://register.fca.= org.uk/. Moneyhub=C2=A0Financial Technology is registe= red in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --0000000000000464af05b68127a7-- From nobody Tue Dec 15 05:58:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6A3A112A for ; Tue, 15 Dec 2020 05:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=moneyhub.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ow8xThJmk2m for ; Tue, 15 Dec 2020 05:58:38 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 EDF603A1174 for ; Tue, 15 Dec 2020 05:58:37 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id b2so21134150edm.3 for ; Tue, 15 Dec 2020 05:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moneyhub.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s+9/Tx7uULV5z47+Ozx9W5JkyE36Np4k7EPEqZlVSr8=; b=i+UvHGkPi8g6iJFzpAbZf0VeLNoJ3vEi4jf1LbJa7V44IQ4PMJ7TOP84upb/wHiWWj kD2xDcv0Msw0JxHKQ1S6MFVnFMgVMN/c+Yr5wW7A72OE3lgjkoF7ju7rbjMC1+v7p47q njEwFCehtVixc5uKSAvGQtpcJv2UN+8y8aE+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s+9/Tx7uULV5z47+Ozx9W5JkyE36Np4k7EPEqZlVSr8=; b=VGS9gGx2Qqd3rgZX/lyEDF+kOImVO7PZbyuf16Z2lRDbvNl2liR8eFiGkns9bGOcWJ ohcdAkFJqpDPW6S9KH0GqRuHqqIW+inadDhs5PH+qTBXDEiKukg6ayGedslrMaW79Jr4 xvTyd5r3tBGZ7ALTe5ipeP+Fu9MvMqk/regn4n/csHmZhf1qKmYRDIUCaSrf0FjWDuFR EEosyuMeBgYwX6lJ2kDsS83qfFAl4MGsabJO6+lg6xLIXhN29vIYeyWX2iPTadx17Hy+ TRex4HzoQ7VEcH7kp7uuC6LPd+rzL/3Me/ThMffLx6k8ibGfyYX1xDC0vY9L2t46HaMP SiuA== X-Gm-Message-State: AOAM530SZn3NFcGGNgZm7YbtfOJiLwKR7qyg9tOoQ13jjUKhRUrESGQv WGfKnxFFWDInSAqGjxukg4JDW72imHYCuxwKTF2DUKFl3qnZPt89OxMYiZ8Z3LH2P3sSEGIdYK/ N2a8DzlhaJYDihMI= X-Google-Smtp-Source: ABdhPJw0eaSh00VhgzM0pV6Oldk4mSdEGdKx9beZ5SLEpJW8NCj5cyNyHGFFKx66kuX8suJuE2T/rayERApmRKIHvQs= X-Received: by 2002:aa7:c492:: with SMTP id m18mr1445358edq.236.1608040716036; Tue, 15 Dec 2020 05:58:36 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: From: Dave Tonge Date: Tue, 15 Dec 2020 14:58:24 +0100 Message-ID: To: Fabien Imbault Cc: Torsten Lodderstedt , Dick Hardt , txauth gnap , Justin Richer , Stephen Moore Content-Type: multipart/alternative; boundary="000000000000aa023905b6812709" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 13:58:45 -0000 --000000000000aa023905b6812709 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A string that can be used to identify the grant in order to get its latest status, continue, update, revoke. Internally an AS will have an identifier for a grant Internally an RC will have an identifier for a grant Why can't we just make this explicit in the protocol. In the current world of OAuth 2 we have - refresh token - PAR - device_code in OAuth Device Flow - grant management - auth_req_id in CIBA - "consent ids" in proprietary APIs They all somehow represent the "grant", but the fact that most of them are tacked on to the existing protocol, causes problems. I really like the fact that GNAP has the current "continue" endpoint built into the spec - allowing "grant management" to be a first class feature of the protocol. But I don't like the fact that an ephemeral rotating token is the identifier for the grant. A failed network request can mean that the RC no longer has access to manage a grant - in fact they may not even be able to reference it when starting a new grant as they may only have access to an expired access token that the AS may not accept. This seems unnecessarily brittle. On Tue, 15 Dec 2020 at 13:52, Fabien Imbault wrote: > Ok, could you be more specific as to what you'd expect for the persistent > identifier ? > Thanks > Fabien > > On Tue, Dec 15, 2020 at 1:50 PM Dave Tonge > wrote: > >> The persistent identifier is not a different issue, the current access >> token is used to reference an existing grant >> >> >> >> It may not be more difficult for a client to *use* an access token at >> the AS / RS. But there is definitely an overhead on the client to >> *manage* this separate access token. >> >> >> >> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault >> wrote: >> >>> I think we always said the access token was different, and handled as a >>> bound token. >>> >>> But it doesn't mean it's more difficult for the client that already >>> needs to be able to handle tokens anyway (bearer or not, both cases cou= ld >>> occur). It's mostly consolidating the logic. >>> >>> You're anticipating a lot of issues which have no specific reason to >>> occur, such as "can't be used with the token management APIs?". The >>> management API is part of the same general flow. >>> Anticipating issues with rotation is useful, but there are also many >>> ways it can be hard to manage through a stateful approach too. And >>> fundamentally, having everything in a common model (both for the intern= als >>> of the AS and for the API calls) will help improve by a large margin wh= at >>> is probably the weakest point in today's infrastructure. But it's early= to >>> be definitive as to the downstream impact either way. >>> >>> As for a persistent identifier instead of a continuation API, and >>> generally the end of your message, it's a totally unrelated issue to th= is >>> PR, so I suggest we don't discuss that here, but in a separate issue if >>> needed. >>> >>> Fabien >>> >>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>> wrote: >>> >>>> So we've established that this is a different access token, that >>>> requires different handling at the client. So keeping it could cause m= ore >>>> confusion? >>>> >>>> As an RC, I will have to store the continue `uri` as although it could >>>> be static it could also be dynamic. Why do I need to store an access t= oken >>>> as well. It brings me no benefit as an RC, in fact it brings more >>>> complexity. As I will now need to manage multiple types of tokens with >>>> different lifecycles: >>>> >>>> *Continuation token* >>>> - can only be used at the continue endpoint (the name of which is >>>> confusing as I can use this endpoint to revoke a grant or get metadata= on >>>> the grant). >>>> - may be rotated each time it is used, or may not be >>>> - provided in the `continue` section of the response >>>> - must be sender-constrained >>>> - can't be used with the token management APIs? >>>> - can be used to identify the grant when making subsequent grants >>>> >>>> *Access token(s) to use at RS* >>>> - can only be used at the specified RS >>>> - may be sender constrained >>>> - when used at the RS, will not result in rotation >>>> >>>> From my perspective, most use-cases will require the RC to have a >>>> persistent identifier for the grant. Why not bring this into the proto= col >>>> and let the AS provide this persistent identifier (through the form of= the >>>> continue uri). Using a rotating access token as a persistent identifie= r >>>> doesn't seem like the right choice. >>>> >>>> I see no security benefit to having the continuation access token. It >>>> doesn't matter if the continue uri leaks as it is useless without an >>>> accompanying signature, i.e. any security benefit of having an access = token >>>> is already provided by having a signature. >>>> >>>> The only benefits that I can see are: >>>> - If the AS wants to be fully stateless, then you can encode more dat= a >>>> in a token than in a uri >>>> - If the AS wants to have a static endpoint for CRUD operations on th= e >>>> grant >>>> - To allow the AS to identity a previous grant >>>> >>>> If we dropped the access token for the continue endpoint and rather >>>> mandated a dynamic uri this would make things conceptually easier to >>>> understand, easier for the RC to implement, easier to debug and less c= hance >>>> of errors when rotating tokens (i.e. race conditions could be quite li= kely >>>> if the AS always rotates the token) >>>> >>>> *One-off grant with no continuation or ongoing management:* >>>> RC sends signature and metadata, no `continue` response provided, >>>> therefore no grant management possible >>>> >>>> *Grant with ongoing management* >>>> RC sends signature and metadata, AS responds with a continue uri that >>>> has these purposes: >>>> - can be used by the RC to continue/update, read or revoke the grant >>>> - can be used by the RC when making a new grant to identify the >>>> previous grant >>>> >>>> As an RC the only permanent items I need to store are: >>>> - the continue uri associated with the grant >>>> - any access tokens I receive for the grant >>>> >>>> Dave >>>> >>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >>>> wrote: >>>> >>>>> Hi Torsten, >>>>> >>>>> You're right on both accounts. >>>>> - for the first remark, it fits quite nicely the init request / >>>>> continuation pattern >>>>> - for the second remark, it is a sort of handle for the >>>>> continuation request, which will eventually lead to the issuance or r= efresh >>>>> of standard access tokens >>>>> >>>>> Having a specific name is a possibility, I actually suggested that to= o >>>>> at some point. >>>>> >>>>> Fabien >>>>> >>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>> torsten@lodderstedt.net> wrote: >>>>> >>>>>> Hi Fabien, >>>>>> >>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>> fabien.imbault@gmail.com>: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > On the contrary your feedback is most welcome. >>>>>> > >>>>>> > It doesn't accept any token, it needs the particular token as >>>>>> described in 3.1 and which is not a bearer token (that's what the "k= ey" : >>>>>> true parameter is supposed to convey). >>>>>> > >>>>>> > Let us know if you need more clarifications. >>>>>> >>>>>> Thanks for the clarification. I think only accepting this kind of >>>>>> token at the continuation is a good idea otherwise the AS would need= to be >>>>>> able to parse and understand all sorts of access tokens. >>>>>> >>>>>> Conceptually, I like the idea to treat the continuation as another >>>>>> kind of resource. However, here are some observations I want to shar= e with >>>>>> you: >>>>>> - This resource is different as it will issue other access tokens (o= f >>>>>> this kind) to be used in subsequent continuation requests. This requ= ires >>>>>> different handing on the client side. >>>>>> - This access token (if I understand correctly) is (or at least feel= s >>>>>> like) a handle for the underlying grant. So it is kind of the super = access >>>>>> token to obtain other access tokens. >>>>>> >>>>>> I would consider using a different term to refer to this special >>>>>> access token, grant token or grant handle for example, in order to p= revent >>>>>> confusion. >>>>>> >>>>>> best regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> > >>>>>> > Best >>>>>> > Fabien >>>>>> > >>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>> > Hi all, >>>>>> > >>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me questio= n seems >>>>>> naive. >>>>>> > >>>>>> > After having skimmed through the current draft and the PR, I=E2=80= =98m not >>>>>> sure whether the continuation requests accepts any access token issu= ed to >>>>>> the RC or the particular access token returned in the =E2=80=9Econti= nue=E2=80=9C element in >>>>>> section 3.1.. >>>>>> > >>>>>> > Can you please shed some light on this? >>>>>> > >>>>>> > kind regards, >>>>>> > Torsten. >>>>>> > >>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>> fabien.imbault@gmail.com>: >>>>>> >> >>>>>> >> =EF=BB=BF >>>>>> >> You're completely right. Allowing the dev to be lazy is a very >>>>>> good thing in general, because it's what we know will work :-) >>>>>> >> >>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore a >>>>>> =C3=A9crit : >>>>>> >> Hi Fabien, >>>>>> >> >>>>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>>>> sort of in the back of my mind, it isn't a huge risk there. So I act= ually >>>>>> agree with Dick there. Something doesn't sit right with me for the u= nique >>>>>> URL solution, so I don't like it and came up with a hypothetical tha= t seems >>>>>> like it could be a down side. >>>>>> >> >>>>>> >> I still think the access token model with the signed request is >>>>>> the way I'd like to go, because again, it's a mechanism I'd be imple= menting >>>>>> anyway to talk to any 'normal' resource. The fact is there is _somet= hing_ >>>>>> representing context that has to pass back and forth here, whether t= hat is >>>>>> an access token (which I feel like is more flexible for extensions e= tc), a >>>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy develo= per ;) >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>> fabien.imbault@gmail.com> wrote: >>>>>> >> Again speaking in my own name here. >>>>>> >> >>>>>> >> Dick, we know you'd prefer to have a different design, but this P= R >>>>>> shouldn't be about that. >>>>>> >> >>>>>> >> Back on your 3 items : >>>>>> >> >>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>> decided that wouldn't be how that would work. We have a client insta= nce >>>>>> that allows a more generic and flexible pattern (which BTW also allo= ws what >>>>>> you want) >>>>>> >> >>>>>> >> 2) instead of blame arguments of who's less >>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversation= s, I >>>>>> suggest we speak in less abstract terms and ask ourselves what that = means >>>>>> in practice for devs. Stephen and several others (myself included) h= ave >>>>>> expressed that it wouldn't be harder to implement, it would even sim= plify >>>>>> things quite a lot. If you disagree please send us a code sample to = really >>>>>> show that point by example, because that's really not obvious. >>>>>> >> >>>>>> >> 3) "If someone has the client credentials, they can impersonate >>>>>> the client, and all bets are off." Are you seriously making this arg= ument? >>>>>> Because if you have a better proposal than using cryptographic keys,= I'm >>>>>> all hears. You make it look like there's a problem, while in reality= we're >>>>>> only relying on the basic assumption of all modern digital communica= tions. >>>>>> >> >>>>>> >> And more importantly you never responded to the issues of how to >>>>>> avoid the security pitfalls of what you proposed. >>>>>> >> >>>>>> >> Fabien >>>>>> >> >>>>>> >> >>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt a >>>>>> =C3=A9crit : >>>>>> >> >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>>> wrote: >>>>>> >> But from the spec: >>>>>> >> " >>>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>>> identify itself by including the client field of the request... >>>>>> >> ... >>>>>> >> key (object / string) : The public key of the RC to be used in >>>>>> this request as described in {{request-key}}. This field is REQUIRED= . >>>>>> >> ... >>>>>> >> " >>>>>> >> So on the initial request, the key will be there. >>>>>> >> >>>>>> >> The client field can be an object or a string. If the client is >>>>>> pre-registered, then a string could be provided instead of an object= . >>>>>> >> >>>>>> >> >>>>>> >> If you don't have the access token, then how do you differentiate >>>>>> between two requests from the same web application by two different = users? >>>>>> Is the web application supposed to have different credentials for ev= ery >>>>>> request? >>>>>> >> >>>>>> >> The AS returns a URI for manipulating the request. I would change >>>>>> the spec so that each request would have a unique URI. This is the u= sually >>>>>> RESTful pattern that the resource (the grant request) has an URI. >>>>>> >> >>>>>> >> >>>>>> >> So in this case, the easy way out is to pass the access token to >>>>>> the client, who then, as i stated before, treats the continue reques= t as a >>>>>> RS call (albeit a specialized version of the RS where the RS is the = AS) OR >>>>>> to use the unique URL, >>>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>>> (What would be the point of that attack, I don't know, I guess if so= meone >>>>>> had the client credentials but not any subjects/resources they could= try to >>>>>> intercept the grant via continue... I just don't feel right locking = things >>>>>> down to unique URLs that way.) >>>>>> >> >>>>>> >> If someone has the client credentials, they can impersonate the >>>>>> client, and all bets are off. >>>>>> >> >>>>>> >> LOTS of RS servers return a resource specific URL -- my proposal >>>>>> is no different. >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>>> wrote: >>>>>> >> Hi Stephen >>>>>> >> >>>>>> >> The client is signing the first request. The key *might* be in th= e >>>>>> body. The client is signing all the subsequent requests as well. The >>>>>> "access token" is not needed by the client to prove it is authorized= as the >>>>>> client is proving it is the same client again. >>>>>> >> >>>>>> >> In other words, I don't see the need for an access token, so it >>>>>> does not need to be put in a URL or an auth header. >>>>>> >> >>>>>> >> If a developer really, really wants to hand context back to the >>>>>> client for subsequent calls, they can put it in the URL or some othe= r >>>>>> method. Putting it in the HTTP Authorization header is confusing bec= ause it >>>>>> is NOT an access token -- it is the context of the request. >>>>>> >> >>>>>> >> =E1=90=A7 >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>>> wrote: >>>>>> >> Even though I've only been lightly following things, I feel the >>>>>> need to voice my preference as a developer since I will probably som= eday >>>>>> have to either write a RC or RS... >>>>>> >> >>>>>> >> The way I see it is the RC makes the initial request to the AS as >>>>>> part of this request, it provides it's key in the body... (So no use= of the >>>>>> Authorization header) >>>>>> >> At this point that request, represented by the continue URL + >>>>>> "Access Token", from my lazy developer standpoint, is a Resource End= point >>>>>> and Access Token, and the AS is acting as a specialized RS in this c= ase. >>>>>> >> So my client posts to whatever URL with the 'access token' in the >>>>>> authorization header, just like acting on any other resource I have = a token >>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>> decision point of "Do I have another continue, or do I have a real t= oken >>>>>> for the resource..." But the mechanism is the same to me in the clie= nt. >>>>>> >> Personally I like that, because if I have an access_token, I >>>>>> already think "Put it in the auth header." >>>>>> >> >>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>> >> -steve >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>> wrote: >>>>>> >> inline ... >>>>>> >> >>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>> wrote: >>>>>> >> Others had already responded to this previous thread, but I wante= d >>>>>> to add a couple points to clarify some things. >>>>>> >> >>>>>> >>> 3) What the client has to do with the "access token" is not the >>>>>> same as access tokens for an RS. The client gets a new "access token= " for >>>>>> each grant request, and for each API call to the AS, and the client = learns >>>>>> it can not make any more API calls for that specific request when it= does >>>>>> not get an "access token" back. This is a completely different desig= n >>>>>> pattern than calling an RS API with an access token, and is a new de= sign >>>>>> pattern for calling APIs. This adds complexity to the client that it= would >>>>>> not normally have, and I don't think GNAP is the right place to star= t a new >>>>>> design pattern. >>>>>> >>> >>>>>> >> >>>>>> >> I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole >>>>>> point of the design is that the client would be doing the same thing= with >>>>>> the access token at the AS that it does with the RS by re-using the = access >>>>>> token structure. Can you please describe what the differences are, a= part >>>>>> from the rotation? Presentation of the token and signing of the mess= age are >>>>>> identical. >>>>>> >> >>>>>> >> The client is getting the "access token" from its API. It is not >>>>>> using an "access_token" in other API calls to the AS. >>>>>> >> >>>>>> >> >>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>> continuation responses is a separate issue to be discussed: >>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>> >> >>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right pla= ce to >>>>>> have new designs =E2=80=94 not that this is one. >>>>>> >> >>>>>> >> You are proposing a new way for an API to provide context for >>>>>> subsequent API calls. Looks out of scope to me. >>>>>> >> >>>>>> >> >>>>>> >>> 4) Clients that only want claims from the AS and no access token= s >>>>>> will be required to support an API calling mechanism they would not = have to >>>>>> support otherwise. >>>>>> >> >>>>>> >> Correct, but the delta between the calls a client would make with >>>>>> and without an access token is vanishingly small. The client has to = sign >>>>>> the initial request in some fashion, and it will sign the continuati= on >>>>>> request in the same exact fashion, but now include an access token i= n that >>>>>> request. >>>>>> >> >>>>>> >> Per my other point, there is no value to me in my implementations >>>>>> of passing context back and forth between the client and AS -- so it= is >>>>>> extra work providing no value. >>>>>> >> >>>>>> >> Also, any client authentication mechanism that wants to use the >>>>>> HTTP Authentication header is precluded from using it. >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> Clients making a request to an AS and not getting an access token >>>>>> is a new design pattern. I think it has value and should be included= , but >>>>>> OAuth today shows us the immense value of getting access tokens for = calling >>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>> >> >>>>>> >>> >>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>> mechanism for a client to delete the request, as the client is not a= llowed >>>>>> to make a call without an "access token". >>>>>> >> >>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>>> is telling this client instance that it can=E2=80=99t do anything el= se with this >>>>>> ongoing request. If the AS wants to allow the client to manage it, i= t will >>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D fi= eld. >>>>>> >> >>>>>> >> There is nuance in that intention. A related concern is that >>>>>> deleting a request does not seem like it is a "continue" operation. >>>>>> >> >>>>>> >> >>>>>> >>> >>>>>> >>> 6) There is no standard identifier for the request. Debugging an= d >>>>>> auditing are hampered by the client and AS having no standard way to >>>>>> identifying a request. While one AS may provide a unique URL for eac= h grant >>>>>> request, another AS may use a persistent "access token" to identify = the >>>>>> grant request, and other ASs may issue a new "access token" on each = API >>>>>> call, providing no persistent identifier for the request. >>>>>> >> >>>>>> >> Debugging and auditing this kind of thing are functions of the AS= . >>>>>> How is interoperability harmed by different ASs having different met= hods to >>>>>> identify their internal data elements? The client doesn=E2=80=99t ne= ed any >>>>>> knowledge of the AS=E2=80=99s identifiers, it just needs to know the= next steps for >>>>>> continuing the negotiation. >>>>>> >> >>>>>> >> Debugging between the client and the AS was what I was referring >>>>>> to. How does a client developer identify the request when communicat= ing to >>>>>> the AS developer. Seems complicated. >>>>>> >> >>>>>> >> =E1=90=A7 >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >> =E1=90=A7 >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >> -- >>>>>> >> TXAuth mailing list >>>>>> >> TXAuth@ietf.org >>>>>> >> >>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo= /txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu0= IQPJJYtSpI >>>>>> >>>>>> -- >>>>> TXAuth mailing list >>>>> TXAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>>> -- >>>> Dave Tonge >>>> CTO >>>> [image: Moneyhub Enterprise] >>>> >>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>>> 6FL >>>> t: +44 (0)117 280 5120 >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at *https://register.fca.org.= uk/ >>>> *. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772 . >>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technolog= y >>>> Limited which is authorised and regulated by the Financial Conduct >>>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>>> Financial Services Register (FRN 809360) at >>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>> registered in England & Wales, company registration number 06909772. >>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise,= Regus >>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>> >>>> DISCLAIMER: This email (including any attachments) is subject to >>>> copyright, and the information in it is confidential. Use of this emai= l or >>>> of any information in it other than by the addressee is unauthorised a= nd >>>> unlawful. Whilst reasonable efforts are made to ensure that any attach= ments >>>> are virus-free, it is the recipient's sole responsibility to scan all >>>> attachments for viruses. All calls and emails to and from this company= may >>>> be monitored and recorded for legitimate purposes relating to this >>>> company's business. Any opinions expressed in this email (or in any >>>> attachments) are those of the author and do not necessarily represent = the >>>> opinions of Moneyhub Financial Technology Limited or of any other grou= p >>>> company. >>>> >>>> >> >> -- >> Dave Tonge >> CTO >> [image: Moneyhub Enterprise] >> >> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6= FL >> t: +44 (0)117 280 5120 >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at *https://register.fca.org.uk= / >> *. Moneyhub Financial Technology is >> registered in England & Wales, company registration number 06909772 . >> Moneyhub Financial Technology Limited 2019 =C2=A9 >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >> Limited which is authorised and regulated by the Financial Conduct >> Authority ("FCA"). Moneyhub Financial Technology is entered on the >> Financial Services Register (FRN 809360) at https://register.fca.org.uk/= . >> Moneyhub Financial Technology is registered in England & Wales, company >> registration number 06909772. Moneyhub Financial Technology Limited 2020= =C2=A9 >> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 >> 6EA. >> >> DISCLAIMER: This email (including any attachments) is subject to >> copyright, and the information in it is confidential. Use of this email = or >> of any information in it other than by the addressee is unauthorised and >> unlawful. Whilst reasonable efforts are made to ensure that any attachme= nts >> are virus-free, it is the recipient's sole responsibility to scan all >> attachments for viruses. All calls and emails to and from this company m= ay >> be monitored and recorded for legitimate purposes relating to this >> company's business. Any opinions expressed in this email (or in any >> attachments) are those of the author and do not necessarily represent th= e >> opinions of Moneyhub Financial Technology Limited or of any other group >> company. >> >> --=20 Dave Tonge CTO [image: Moneyhub Enterprise] Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL t: +44 (0)117 280 5120 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at *https://register.fca.org.uk/ *. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772 . Moneyhub Financial Technology Limited 2019 =C2=A9 DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000aa023905b6812709 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    A string that can be used to identify the grant in order t= o get its latest status, continue, update, revoke.

    Internall= y an AS will have an identifier for a grant
    Internally an RC will have= an identifier for a grant
    Why can't we just make this explicit=C2= =A0in the protocol.

    In the current world of OAuth 2 we have<= /div>
    =C2=A0- refresh token
    =C2=A0- PAR
    =C2=A0- device_code in OAu= th Device Flow
    =C2=A0- grant management
    =C2= =A0- auth_req_id in CIBA
    =C2=A0- "consent ids" in proprietar= y APIs

    They all somehow represent the "grant", but= the fact that most of them are tacked on to the existing protocol, causes = problems.=C2=A0

    I really like the fact that GNAP has the cur= rent "continue" endpoint built into the spec - allowing "gra= nt management" to be a first class feature of the protocol. But I don&= #39;t like the fact that an ephemeral=C2=A0rotating token is the identifier= for the grant.=C2=A0

    A failed network request can mean that= the RC no longer has access to manage a grant - in fact they may not even = be able to reference it when starting a new grant as they may only have acc= ess to an expired access token that the AS may not accept. This seems unnec= essarily=C2=A0brittle.=C2=A0

    On Tue, 15 Dec 2020 at 13:52, Fabien Imba= ult <fabien.imbault@gmail.co= m> wrote:
    Ok, could you be more specific as to what you'd expec= t for the persistent identifier ?
    Thanks
    Fabien
    On Tue, = Dec 15, 2020 at 1:50 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    reference an existing gran= t=C2=A0

    It may not be more dif= ficult for a client to use an access token at the AS / RS. But there= =C2=A0is definitely an overhead on the client to manage=C2=A0this se= parate access token.=C2=A0



    On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <fabien.imbault@gmail.com> wrote= :
    I think we always said the access token was different, and handled as a = bound token.

    But it doesn't mean it's more diffi= cult for the client that already needs to be able to handle tokens anyway (= bearer or not, both cases could occur). It's mostly consolidating the l= ogic.

    You're anticipating a lot of issues= which have no specific reason to occur, such as "can't be used with the toke= n management APIs?". The management API is part of the same general fl= ow.
    Anticipating issues with rotation is useful, but there are also m= any ways it can be hard to manage through a stateful approach too. And fund= amentally, having everything in a common model (both for the internals of t= he AS and for the API calls) will help improve by a large margin what is pr= obably the weakest point in today's infrastructure. But it's early = to be definitive as to the downstream impact either way.=C2=A0 =C2=A0

    As for a persistent identifier instead of a continuation AP= I, and generally the end of your message, it's a totally unrelated issu= e to this PR, so I suggest we don't discuss that here, but in a separat= e issue if needed.

    Fabien
    =
    On Tue= , Dec 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    So we've established that this is a different access token, that r= equires different handling at the client. So keeping it could cause more co= nfusion?

    As an RC, I will have to st= ore the continue `uri` as although it could be static it could also be dyna= mic. Why do I need to store an access token as well.=C2=A0It brings me no b= enefit as an RC, in fact it brings more complexity. As I will now need to m= anage multiple types of tokens with different lifecycles:
    Continuation token=C2=A0
    = =C2=A0 - can only be used at the continue endpoint (the name of which is co= nfusing as I can use this endpoint to revoke a grant or get metadata on the= grant).
    =C2=A0- may be rotated each time it is used, or m= ay not be
    =C2=A0- provided in the `continue` section of th= e response
    =C2=A0- must be sender-constrained
    =C2=A0- can't be used with the token management APIs?
    =C2=A0- can be used to identify the grant when making subsequent grant= s

    Access token(s) to use at RS
    =C2=A0=C2=A0- can only be used at the specified R= S
    =C2=A0 - may be sender constrained
    =C2= =A0 - when used at the RS, will not result in rotation
    From my perspective, most use-cases will require the RC = to have a persistent identifier for the grant. Why not bring this into the = protocol and let the AS provide this persistent identifier (through the for= m of the continue uri). Using a rotating access token as a persistent ident= ifier doesn't seem like the right choice.=C2=A0

    I see no security benefit to having the continuation access= token. It doesn't matter if the continue uri leaks as it is useless wi= thout an accompanying signature, i.e. any security benefit of having an acc= ess token is already provided by having a signature.

    <= /div>
    The only benefits that I can see are:
    =C2= =A0- If the AS wants to be fully stateless, then you can encode more data i= n a token than in a uri
    =C2=A0- If the AS wants to have a = static endpoint for CRUD operations on the grant
    =C2=A0- T= o allow the AS to identity a previous grant

    If we dropped the access token for the continue endpoint and rather= mandated a dynamic uri this would make things conceptually easier to under= stand, easier for the RC to implement, easier to debug and less chance of e= rrors when rotating tokens (i.e. race conditions could be quite likely if t= he AS always rotates the token)

    O= ne-off grant with no continuation or ongoing management:
    RC sends signature and metadata, no `continue` response provided, theref= ore no grant management possible

    = Grant with ongoing management
    RC sends signature and= metadata, AS responds with a continue uri that has these purposes:
    =C2=A0- can be used by the RC to continue/update, read or revoke = the grant
    =C2=A0- can be used by the RC when making a new = grant to identify the previous grant

    = =C2=A0- the continue uri associated with the grant
    =C2=A0-= any access tokens I receive for the grant

    Dave

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <fabien.imbault@gmail= .com> wrote:
    Hi Torsten,=C2=A0

    You're right = on both accounts.=C2=A0
    - for the first remark, it fits quite nic= ely the init request=C2=A0 / continuation pattern=C2=A0
    - for the= second remark, it is a sort of handle for the continuation=C2=A0request, w= hich will eventually lead to the issuance or refresh of standard access tok= ens=C2=A0

    Having a specific=C2=A0name is a possibi= lity, I actually suggested that too at some point.=C2=A0

    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <= torsten@lodder= stedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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




    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology= , 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:= =C2=A0+44 (0)117= 280 5120

    Moneyhub Enterprise is a trading style of Moneyhu= b Financial Technology Limited which is authorised and regulated by the Fin= ancial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technol= ogy is entered on the Financial Services Register=C2=A0(= FRN=C2=A0809360) at https://register.fca= .org.uk/. Moneyhub=C2=A0Financial Technology is regist= ered in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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




    --
    Dave = Tonge
    CTO
    3D"Moneyhub<= /div>
    Mo= neyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2=A0+44 (0)117 280 5120

    Moneyhub Enterprise is= a trading style of Moneyhub Financial Technology Limited which is authoris= ed and regulated by the Financial Conduct Authority ("FCA").=C2= =A0Moneyhub Financial Technology is entered on the Financial Services Regis= ter=C2=A0(FRN=C2=A0809360) at https://register.fca.org.uk/. Moneyhub=C2=A0F= inancial Technology is registered in England & Wales, company registrat= ion number=C2=A0=C2=A00= 6909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limit= ed 2019=C2=A0=C2=A9

    <= div style=3D"color:rgb(51,51,51);font-family:lato,"open sans",ari= al,sans-serif;font-size:14px;letter-spacing:normal;line-height:1.4">DISCLAIMER: This email (including any attachments) is subject to copyrig= ht, and the information in it is confidential. Use of this email or of any = information in it other than by the addressee is unauthorised and unlawful.= Whilst reasonable efforts are made to ensure that any attachments are viru= s-free, it is the recipient's sole responsibility to scan all attachmen= ts for viruses. All calls and emails to and from this company may be monito= red and recorded for legitimate purposes relating to this company's bus= iness. Any opinions expressed in this email (or in any attachments) are tho= se of the author and do not necessarily represent the opinions of Moneyhub = Financial Technology Limited or of any other group company.

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

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


    --000000000000aa023905b6812709-- From nobody Tue Dec 15 06:11:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE29F3A1139 for ; Tue, 15 Dec 2020 06:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwvk1JtfLGI7 for ; Tue, 15 Dec 2020 06:11:34 -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 8B9F03A1137 for ; Tue, 15 Dec 2020 06:11:34 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id z136so20608096iof.3 for ; Tue, 15 Dec 2020 06:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1MLY1eFZ3d8ZcPs7OrLV/ES9QyQ2BwHC7yahrfcEOf8=; b=PUTPZRsxqNTj4YATEq8TSegujzO5Uv3X83wJ39ACFuP0U9jUu1Ntpja9T6qcAMgqp1 fHILPDhOS2l5bmiW1ycDb7b+WDZpz4dH5lwHARtFbEVat74KW6TuDJv7KkCiKJnTsqwM gOKWuQL3rRH34owRyQOT+32lCHIXHGzatSTqlIv5IDkS6CAODpG/+o3JYZSEkrCvC5n0 SeM8Upwspn9IqyZq5xEAnsZQUzmIt2DzL75ghASh8mZ71Gcu8MNE4Hu20EIvmeNxA0hg 1lsPseV2QC72xlKIfx1sLK9obFcXL3bx1hnoJmcidD07n3GvhHOIJnDyV2nrM6cjj0r5 vrKQ== 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=1MLY1eFZ3d8ZcPs7OrLV/ES9QyQ2BwHC7yahrfcEOf8=; b=MdNRMjYM9zgv0LIxHS2/q6T17dp8M6087cx8UBkEB5A3sSlibEJ4Ds8s4uDmukwcIp VFgESZdWR9mNUBYoQSrjFA5MfcrB0hyeSLzAhxAdAD2jQ1SqMmlO19iboBaS6sTZ5O0Q ORtj2sX/8qiaxP4NQtxi8J7nMzefjM38qsaed2VDvxzxgXY5sU3TnasUnJqAwwS6gZaO 5OjVqEXOIC7yBFbVzH/+G3ChOiLHFPsAWlA+ifDJ6d2FmkY9hb+0pk7oDDZ750LLDKhM iJpPFPZnXYclszRroh0EfprQyv9AKtypObBwvSZohZ68pqwVQp5TeyVE1Q83Y1aVriz6 +j+w== X-Gm-Message-State: AOAM532Z45azXuaFOLPmYUkOO2TCJKWDH8TcM/cC+X8KOUfLbYALvndZ XH7KeAgxlH81VpLnf6Dc36RVqTz5EuYpmE3WaoH4A5rPAd7gMQ== X-Google-Smtp-Source: ABdhPJwtFW1cBUBuI6t4c/Yxmfsd7GASvE2QKDpxScO6gokx2ZZ+WiUcpLt4bi4rA8B0aFyy0OQJ6Cdu/56zCVq0cXg= X-Received: by 2002:a05:6638:153:: with SMTP id y19mr39316180jao.47.1608041493699; Tue, 15 Dec 2020 06:11:33 -0800 (PST) MIME-Version: 1.0 References: <6B1CCD2C-431C-4C99-9898-E0CD447C5811@lodderstedt.net> In-Reply-To: From: Fabien Imbault Date: Tue, 15 Dec 2020 15:11:20 +0100 Message-ID: To: Warren Parad Cc: Dave Tonge , Stephen Moore , Torsten Lodderstedt , txauth gnap , Justin Richer , Dick Hardt Content-Type: multipart/alternative; boundary="0000000000000421e205b6815683" Archived-At: Subject: Re: [GNAP] Consensus Call on Continuation Request 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, 15 Dec 2020 14:11:40 -0000 --0000000000000421e205b6815683 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there Comments embedded Thxs On Tue, Dec 15, 2020 at 2:58 PM Warren Parad wrote: > Beyond what we're covering here, I see at least one important service tha= t >> would directly benefit from tokens, around introspection/management api >> (e.g. is the token still valid?). Here there's no information lookup abo= ut >> a grant, we could just query a bloom filter if we get the authorization = to >> do so. I agree it's not yet included but it's perfectly feasible. > > I think we are so focused on the "we can do this and this and thin with > it" that we aren't thinking about why we *need *it. Instead of what can > be done we should be thinking about, "what can't be done without it" or > even perhaps "With it we won't have to..." > [FI] I guess we're all guilty of "why not" now and then. But in this specific case, the need is pretty clear and directly related to the revocation features we've been discussing. > > For instance, it's easy to construct an argument against hypothetical > value it could provide in cases that don't exist yet. Equally vacuous > arguments could be made for coupling to the future apis/services endpoint= s > when necessary as well as delaying adding the session token to the spec > until after it is necessary. > > Plus the problem is not that you control the AS URI, it's that you have >> only limited trust for what's in front of that. A bound access token >> ensures that your call is anthenticated with the same key as before, whi= le >> the alternative doesn't. > > Could you say more about the potential problem here, I'm not totally > following. > [FI] not a big deal when people use a library, but otherwise end developers may just end up copying the URI directly, not checking the TLD+1. With a basic stateless URL, a simple compare is enough. > > Conceptually, I like the idea to treat the continuation as another kind o= f >> resource. > > Exactly, and why not. Further just as we can return arbitrary urls in the > body of a request, why not utilize the hardened REST patterns and return > them in for instance a Location header. By encouraging custom responses > having to reassemble future requests we are implicitly saying "We don't > like any of the existing recommended patterns", and while it's totally ok= ay > to digress from them, we should have a really good reason to do so. > [FI] where did you see that we don't follow any of the existing recommended patterns? > > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Tue, Dec 15, 2020 at 1:53 PM Fabien Imbault > wrote: > >> Ok, could you be more specific as to what you'd expect for the persisten= t >> identifier ? >> Thanks >> Fabien >> >> On Tue, Dec 15, 2020 at 1:50 PM Dave Tonge >> wrote: >> >>> The persistent identifier is not a different issue, the current access >>> token is used to reference an existing grant >>> >>> >>> >>> It may not be more difficult for a client to *use* an access token at >>> the AS / RS. But there is definitely an overhead on the client to >>> *manage* this separate access token. >>> >>> >>> >>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault >>> wrote: >>> >>>> I think we always said the access token was different, and handled as = a >>>> bound token. >>>> >>>> But it doesn't mean it's more difficult for the client that already >>>> needs to be able to handle tokens anyway (bearer or not, both cases co= uld >>>> occur). It's mostly consolidating the logic. >>>> >>>> You're anticipating a lot of issues which have no specific reason to >>>> occur, such as "can't be used with the token management APIs?". The >>>> management API is part of the same general flow. >>>> Anticipating issues with rotation is useful, but there are also many >>>> ways it can be hard to manage through a stateful approach too. And >>>> fundamentally, having everything in a common model (both for the inter= nals >>>> of the AS and for the API calls) will help improve by a large margin w= hat >>>> is probably the weakest point in today's infrastructure. But it's earl= y to >>>> be definitive as to the downstream impact either way. >>>> >>>> As for a persistent identifier instead of a continuation API, and >>>> generally the end of your message, it's a totally unrelated issue to t= his >>>> PR, so I suggest we don't discuss that here, but in a separate issue i= f >>>> needed. >>>> >>>> Fabien >>>> >>>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge >>>> wrote: >>>> >>>>> So we've established that this is a different access token, that >>>>> requires different handling at the client. So keeping it could cause = more >>>>> confusion? >>>>> >>>>> As an RC, I will have to store the continue `uri` as although it coul= d >>>>> be static it could also be dynamic. Why do I need to store an access = token >>>>> as well. It brings me no benefit as an RC, in fact it brings more >>>>> complexity. As I will now need to manage multiple types of tokens wit= h >>>>> different lifecycles: >>>>> >>>>> *Continuation token* >>>>> - can only be used at the continue endpoint (the name of which is >>>>> confusing as I can use this endpoint to revoke a grant or get metadat= a on >>>>> the grant). >>>>> - may be rotated each time it is used, or may not be >>>>> - provided in the `continue` section of the response >>>>> - must be sender-constrained >>>>> - can't be used with the token management APIs? >>>>> - can be used to identify the grant when making subsequent grants >>>>> >>>>> *Access token(s) to use at RS* >>>>> - can only be used at the specified RS >>>>> - may be sender constrained >>>>> - when used at the RS, will not result in rotation >>>>> >>>>> From my perspective, most use-cases will require the RC to have a >>>>> persistent identifier for the grant. Why not bring this into the prot= ocol >>>>> and let the AS provide this persistent identifier (through the form o= f the >>>>> continue uri). Using a rotating access token as a persistent identifi= er >>>>> doesn't seem like the right choice. >>>>> >>>>> I see no security benefit to having the continuation access token. It >>>>> doesn't matter if the continue uri leaks as it is useless without an >>>>> accompanying signature, i.e. any security benefit of having an access= token >>>>> is already provided by having a signature. >>>>> >>>>> The only benefits that I can see are: >>>>> - If the AS wants to be fully stateless, then you can encode more >>>>> data in a token than in a uri >>>>> - If the AS wants to have a static endpoint for CRUD operations on >>>>> the grant >>>>> - To allow the AS to identity a previous grant >>>>> >>>>> If we dropped the access token for the continue endpoint and rather >>>>> mandated a dynamic uri this would make things conceptually easier to >>>>> understand, easier for the RC to implement, easier to debug and less = chance >>>>> of errors when rotating tokens (i.e. race conditions could be quite l= ikely >>>>> if the AS always rotates the token) >>>>> >>>>> *One-off grant with no continuation or ongoing management:* >>>>> RC sends signature and metadata, no `continue` response provided, >>>>> therefore no grant management possible >>>>> >>>>> *Grant with ongoing management* >>>>> RC sends signature and metadata, AS responds with a continue uri that >>>>> has these purposes: >>>>> - can be used by the RC to continue/update, read or revoke the grant >>>>> - can be used by the RC when making a new grant to identify the >>>>> previous grant >>>>> >>>>> As an RC the only permanent items I need to store are: >>>>> - the continue uri associated with the grant >>>>> - any access tokens I receive for the grant >>>>> >>>>> Dave >>>>> >>>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault >>>>> wrote: >>>>> >>>>>> Hi Torsten, >>>>>> >>>>>> You're right on both accounts. >>>>>> - for the first remark, it fits quite nicely the init request / >>>>>> continuation pattern >>>>>> - for the second remark, it is a sort of handle for the >>>>>> continuation request, which will eventually lead to the issuance or = refresh >>>>>> of standard access tokens >>>>>> >>>>>> Having a specific name is a possibility, I actually suggested that >>>>>> too at some point. >>>>>> >>>>>> Fabien >>>>>> >>>>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt < >>>>>> torsten@lodderstedt.net> wrote: >>>>>> >>>>>>> Hi Fabien, >>>>>>> >>>>>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault < >>>>>>> fabien.imbault@gmail.com>: >>>>>>> > >>>>>>> > Hi, >>>>>>> > >>>>>>> > On the contrary your feedback is most welcome. >>>>>>> > >>>>>>> > It doesn't accept any token, it needs the particular token as >>>>>>> described in 3.1 and which is not a bearer token (that's what the "= key" : >>>>>>> true parameter is supposed to convey). >>>>>>> > >>>>>>> > Let us know if you need more clarifications. >>>>>>> >>>>>>> Thanks for the clarification. I think only accepting this kind of >>>>>>> token at the continuation is a good idea otherwise the AS would nee= d to be >>>>>>> able to parse and understand all sorts of access tokens. >>>>>>> >>>>>>> Conceptually, I like the idea to treat the continuation as another >>>>>>> kind of resource. However, here are some observations I want to sha= re with >>>>>>> you: >>>>>>> - This resource is different as it will issue other access tokens >>>>>>> (of this kind) to be used in subsequent continuation requests. This >>>>>>> requires different handing on the client side. >>>>>>> - This access token (if I understand correctly) is (or at least >>>>>>> feels like) a handle for the underlying grant. So it is kind of the= super >>>>>>> access token to obtain other access tokens. >>>>>>> >>>>>>> I would consider using a different term to refer to this special >>>>>>> access token, grant token or grant handle for example, in order to = prevent >>>>>>> confusion. >>>>>>> >>>>>>> best regards, >>>>>>> Torsten. >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > Best >>>>>>> > Fabien >>>>>>> > >>>>>>> > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt < >>>>>>> torsten@lodderstedt.net> a =C3=A9crit : >>>>>>> > Hi all, >>>>>>> > >>>>>>> > I didn=E2=80=99t follow GNAP closely so bear with me if me questi= on seems >>>>>>> naive. >>>>>>> > >>>>>>> > After having skimmed through the current draft and the PR, I=E2= =80=98m not >>>>>>> sure whether the continuation requests accepts any access token iss= ued to >>>>>>> the RC or the particular access token returned in the =E2=80=9Econt= inue=E2=80=9C element in >>>>>>> section 3.1.. >>>>>>> > >>>>>>> > Can you please shed some light on this? >>>>>>> > >>>>>>> > kind regards, >>>>>>> > Torsten. >>>>>>> > >>>>>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault < >>>>>>> fabien.imbault@gmail.com>: >>>>>>> >> >>>>>>> >> =EF=BB=BF >>>>>>> >> You're completely right. Allowing the dev to be lazy is a very >>>>>>> good thing in general, because it's what we know will work :-) >>>>>>> >> >>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore >>>>>>> a =C3=A9crit : >>>>>>> >> Hi Fabien, >>>>>>> >> >>>>>>> >> For #3) Even after I typed out the hypothetical attack, that was >>>>>>> sort of in the back of my mind, it isn't a huge risk there. So I ac= tually >>>>>>> agree with Dick there. Something doesn't sit right with me for the = unique >>>>>>> URL solution, so I don't like it and came up with a hypothetical th= at seems >>>>>>> like it could be a down side. >>>>>>> >> >>>>>>> >> I still think the access token model with the signed request is >>>>>>> the way I'd like to go, because again, it's a mechanism I'd be impl= ementing >>>>>>> anyway to talk to any 'normal' resource. The fact is there is _some= thing_ >>>>>>> representing context that has to pass back and forth here, whether = that is >>>>>>> an access token (which I feel like is more flexible for extensions = etc), a >>>>>>> unique url, or even a cookie sent in the cookie header. So just to >>>>>>> re-iterate, I'm a +1 on this pull request, speaking as a lazy devel= oper ;) >>>>>>> >> -steve >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault < >>>>>>> fabien.imbault@gmail.com> wrote: >>>>>>> >> Again speaking in my own name here. >>>>>>> >> >>>>>>> >> Dick, we know you'd prefer to have a different design, but this >>>>>>> PR shouldn't be about that. >>>>>>> >> >>>>>>> >> Back on your 3 items : >>>>>>> >> >>>>>>> >> 1) yes we could make pre-register mandatory, but we already >>>>>>> decided that wouldn't be how that would work. We have a client inst= ance >>>>>>> that allows a more generic and flexible pattern (which BTW also all= ows what >>>>>>> you want) >>>>>>> >> >>>>>>> >> 2) instead of blame arguments of who's less >>>>>>> restful/HATEOAS/whatever that have the tenancy to flame conversatio= ns, I >>>>>>> suggest we speak in less abstract terms and ask ourselves what that= means >>>>>>> in practice for devs. Stephen and several others (myself included) = have >>>>>>> expressed that it wouldn't be harder to implement, it would even si= mplify >>>>>>> things quite a lot. If you disagree please send us a code sample to= really >>>>>>> show that point by example, because that's really not obvious. >>>>>>> >> >>>>>>> >> 3) "If someone has the client credentials, they can impersonate >>>>>>> the client, and all bets are off." Are you seriously making this ar= gument? >>>>>>> Because if you have a better proposal than using cryptographic keys= , I'm >>>>>>> all hears. You make it look like there's a problem, while in realit= y we're >>>>>>> only relying on the basic assumption of all modern digital communic= ations. >>>>>>> >> >>>>>>> >> And more importantly you never responded to the issues of how to >>>>>>> avoid the security pitfalls of what you proposed. >>>>>>> >> >>>>>>> >> Fabien >>>>>>> >> >>>>>>> >> >>>>>>> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt >>>>>>> a =C3=A9crit : >>>>>>> >> >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore >>>>>>> wrote: >>>>>>> >> But from the spec: >>>>>>> >> " >>>>>>> >> When sending a non-continuation request to the AS, the RC MUST >>>>>>> identify itself by including the client field of the request... >>>>>>> >> ... >>>>>>> >> key (object / string) : The public key of the RC to be used in >>>>>>> this request as described in {{request-key}}. This field is REQUIRE= D. >>>>>>> >> ... >>>>>>> >> " >>>>>>> >> So on the initial request, the key will be there. >>>>>>> >> >>>>>>> >> The client field can be an object or a string. If the client is >>>>>>> pre-registered, then a string could be provided instead of an objec= t. >>>>>>> >> >>>>>>> >> >>>>>>> >> If you don't have the access token, then how do you differentiat= e >>>>>>> between two requests from the same web application by two different= users? >>>>>>> Is the web application supposed to have different credentials for e= very >>>>>>> request? >>>>>>> >> >>>>>>> >> The AS returns a URI for manipulating the request. I would chang= e >>>>>>> the spec so that each request would have a unique URI. This is the = usually >>>>>>> RESTful pattern that the resource (the grant request) has an URI. >>>>>>> >> >>>>>>> >> >>>>>>> >> So in this case, the easy way out is to pass the access token to >>>>>>> the client, who then, as i stated before, treats the continue reque= st as a >>>>>>> RS call (albeit a specialized version of the RS where the RS is the= AS) OR >>>>>>> to use the unique URL, >>>>>>> >> but that seems open to a brute force attack by a malicious RC. >>>>>>> (What would be the point of that attack, I don't know, I guess if s= omeone >>>>>>> had the client credentials but not any subjects/resources they coul= d try to >>>>>>> intercept the grant via continue... I just don't feel right locking= things >>>>>>> down to unique URLs that way.) >>>>>>> >> >>>>>>> >> If someone has the client credentials, they can impersonate the >>>>>>> client, and all bets are off. >>>>>>> >> >>>>>>> >> LOTS of RS servers return a resource specific URL -- my proposal >>>>>>> is no different. >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> -steve >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt >>>>>>> wrote: >>>>>>> >> Hi Stephen >>>>>>> >> >>>>>>> >> The client is signing the first request. The key *might* be in >>>>>>> the body. The client is signing all the subsequent requests as well= . The >>>>>>> "access token" is not needed by the client to prove it is authorize= d as the >>>>>>> client is proving it is the same client again. >>>>>>> >> >>>>>>> >> In other words, I don't see the need for an access token, so it >>>>>>> does not need to be put in a URL or an auth header. >>>>>>> >> >>>>>>> >> If a developer really, really wants to hand context back to the >>>>>>> client for subsequent calls, they can put it in the URL or some oth= er >>>>>>> method. Putting it in the HTTP Authorization header is confusing be= cause it >>>>>>> is NOT an access token -- it is the context of the request. >>>>>>> >> >>>>>>> >> =E1=90=A7 >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore >>>>>>> wrote: >>>>>>> >> Even though I've only been lightly following things, I feel the >>>>>>> need to voice my preference as a developer since I will probably so= meday >>>>>>> have to either write a RC or RS... >>>>>>> >> >>>>>>> >> The way I see it is the RC makes the initial request to the AS a= s >>>>>>> part of this request, it provides it's key in the body... (So no us= e of the >>>>>>> Authorization header) >>>>>>> >> At this point that request, represented by the continue URL + >>>>>>> "Access Token", from my lazy developer standpoint, is a Resource En= dpoint >>>>>>> and Access Token, and the AS is acting as a specialized RS in this = case. >>>>>>> >> So my client posts to whatever URL with the 'access token' in th= e >>>>>>> authorization header, just like acting on any other resource I have= a token >>>>>>> for. YES, I get a new token value to use every call, and there is a >>>>>>> decision point of "Do I have another continue, or do I have a real = token >>>>>>> for the resource..." But the mechanism is the same to me in the cli= ent. >>>>>>> >> Personally I like that, because if I have an access_token, I >>>>>>> already think "Put it in the auth header." >>>>>>> >> >>>>>>> >> So my vote would be +1 for the pull request at this time. >>>>>>> >> -steve >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt >>>>>>> wrote: >>>>>>> >> inline ... >>>>>>> >> >>>>>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer >>>>>>> wrote: >>>>>>> >> Others had already responded to this previous thread, but I >>>>>>> wanted to add a couple points to clarify some things. >>>>>>> >> >>>>>>> >>> 3) What the client has to do with the "access token" is not the >>>>>>> same as access tokens for an RS. The client gets a new "access toke= n" for >>>>>>> each grant request, and for each API call to the AS, and the client= learns >>>>>>> it can not make any more API calls for that specific request when i= t does >>>>>>> not get an "access token" back. This is a completely different desi= gn >>>>>>> pattern than calling an RS API with an access token, and is a new d= esign >>>>>>> pattern for calling APIs. This adds complexity to the client that i= t would >>>>>>> not normally have, and I don't think GNAP is the right place to sta= rt a new >>>>>>> design pattern. >>>>>>> >>> >>>>>>> >> >>>>>>> >> I=E2=80=99m not sure what you mean by these being different =E2= =80=94 the whole >>>>>>> point of the design is that the client would be doing the same thin= g with >>>>>>> the access token at the AS that it does with the RS by re-using the= access >>>>>>> token structure. Can you please describe what the differences are, = apart >>>>>>> from the rotation? Presentation of the token and signing of the mes= sage are >>>>>>> identical. >>>>>>> >> >>>>>>> >> The client is getting the "access token" from its API. It is not >>>>>>> using an "access_token" in other API calls to the AS. >>>>>>> >> >>>>>>> >> >>>>>>> >> Rotation of the access token and artifacts for ongoing >>>>>>> continuation responses is a separate issue to be discussed: >>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>>>>>> >> >>>>>>> >> And for what it=E2=80=99s worth, GNAP is absolutely the right pl= ace to >>>>>>> have new designs =E2=80=94 not that this is one. >>>>>>> >> >>>>>>> >> You are proposing a new way for an API to provide context for >>>>>>> subsequent API calls. Looks out of scope to me. >>>>>>> >> >>>>>>> >> >>>>>>> >>> 4) Clients that only want claims from the AS and no access >>>>>>> tokens will be required to support an API calling mechanism they wo= uld not >>>>>>> have to support otherwise. >>>>>>> >> >>>>>>> >> Correct, but the delta between the calls a client would make wit= h >>>>>>> and without an access token is vanishingly small. The client has to= sign >>>>>>> the initial request in some fashion, and it will sign the continuat= ion >>>>>>> request in the same exact fashion, but now include an access token = in that >>>>>>> request. >>>>>>> >> >>>>>>> >> Per my other point, there is no value to me in my implementation= s >>>>>>> of passing context back and forth between the client and AS -- so i= t is >>>>>>> extra work providing no value. >>>>>>> >> >>>>>>> >> Also, any client authentication mechanism that wants to use the >>>>>>> HTTP Authentication header is precluded from using it. >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> Clients making a request to an AS and not getting an access toke= n >>>>>>> is a new design pattern. I think it has value and should be include= d, but >>>>>>> OAuth today shows us the immense value of getting access tokens for= calling >>>>>>> APIs, and so we shouldn=E2=80=99t optimize away from that pattern. >>>>>>> >> >>>>>>> >>> >>>>>>> >>> 5) If the AS does not provide an "access token", there is no >>>>>>> mechanism for a client to delete the request, as the client is not = allowed >>>>>>> to make a call without an "access token". >>>>>>> >> >>>>>>> >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then >>>>>>> the client can=E2=80=99t delete the request =E2=80=94 and yes, that= =E2=80=99s intentional. The AS >>>>>>> is telling this client instance that it can=E2=80=99t do anything e= lse with this >>>>>>> ongoing request. If the AS wants to allow the client to manage it, = it will >>>>>>> include the mechanisms to do so in the =E2=80=9Ccontinue=E2=80=9D f= ield. >>>>>>> >> >>>>>>> >> There is nuance in that intention. A related concern is that >>>>>>> deleting a request does not seem like it is a "continue" operation. >>>>>>> >> >>>>>>> >> >>>>>>> >>> >>>>>>> >>> 6) There is no standard identifier for the request. Debugging >>>>>>> and auditing are hampered by the client and AS having no standard w= ay to >>>>>>> identifying a request. While one AS may provide a unique URL for ea= ch grant >>>>>>> request, another AS may use a persistent "access token" to identify= the >>>>>>> grant request, and other ASs may issue a new "access token" on each= API >>>>>>> call, providing no persistent identifier for the request. >>>>>>> >> >>>>>>> >> Debugging and auditing this kind of thing are functions of the >>>>>>> AS. How is interoperability harmed by different ASs having differen= t >>>>>>> methods to identify their internal data elements? The client doesn= =E2=80=99t need >>>>>>> any knowledge of the AS=E2=80=99s identifiers, it just needs to kno= w the next steps >>>>>>> for continuing the negotiation. >>>>>>> >> >>>>>>> >> Debugging between the client and the AS was what I was referring >>>>>>> to. How does a client developer identify the request when communica= ting to >>>>>>> the AS developer. Seems complicated. >>>>>>> >> >>>>>>> >> =E1=90=A7 >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >> =E1=90=A7 >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >> -- >>>>>>> >> TXAuth mailing list >>>>>>> >> TXAuth@ietf.org >>>>>>> >> >>>>>>> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinf= o/txauth&source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4qVOu= 0IQPJJYtSpI >>>>>>> >>>>>>> -- >>>>>> TXAuth mailing list >>>>>> TXAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Tonge >>>>> CTO >>>>> [image: Moneyhub Enterprise] >>>>> >>>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS= 1 >>>>> 6FL >>>>> t: +44 (0)117 280 5120 >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at *https://register.fca.org= .uk/ >>>>> *. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772 = . >>>>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> Moneyhub Enterprise is a trading style of Moneyhub Financial >>>>> Technology Limited which is authorised and regulated by the Financial >>>>> Conduct Authority ("FCA"). Moneyhub Financial Technology is entered o= n the >>>>> Financial Services Register (FRN 809360) at >>>>> https://register.fca.org.uk/. Moneyhub Financial Technology is >>>>> registered in England & Wales, company registration number 06909772. >>>>> Moneyhub Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise= , Regus >>>>> Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. >>>>> >>>>> DISCLAIMER: This email (including any attachments) is subject to >>>>> copyright, and the information in it is confidential. Use of this ema= il or >>>>> of any information in it other than by the addressee is unauthorised = and >>>>> unlawful. Whilst reasonable efforts are made to ensure that any attac= hments >>>>> are virus-free, it is the recipient's sole responsibility to scan all >>>>> attachments for viruses. All calls and emails to and from this compan= y may >>>>> be monitored and recorded for legitimate purposes relating to this >>>>> company's business. Any opinions expressed in this email (or in any >>>>> attachments) are those of the author and do not necessarily represent= the >>>>> opinions of Moneyhub Financial Technology Limited or of any other gro= up >>>>> company. >>>>> >>>>> >>> >>> -- >>> Dave Tonge >>> CTO >>> [image: Moneyhub Enterprise] >>> >>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 >>> 6FL >>> t: +44 (0)117 280 5120 >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at *https://register.fca.org.u= k/ >>> *. Moneyhub Financial Technology is >>> registered in England & Wales, company registration number 06909772 . >>> Moneyhub Financial Technology Limited 2019 =C2=A9 >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology >>> Limited which is authorised and regulated by the Financial Conduct >>> Authority ("FCA"). Moneyhub Financial Technology is entered on the >>> Financial Services Register (FRN 809360) at https://register.fca.org.uk= /. >>> Moneyhub Financial Technology is registered in England & Wales, company >>> registration number 06909772. Moneyhub Financial Technology Limited 202= 0 =C2=A9 >>> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS= 1 >>> 6EA. >>> >>> DISCLAIMER: This email (including any attachments) is subject to >>> copyright, and the information in it is confidential. Use of this email= or >>> of any information in it other than by the addressee is unauthorised an= d >>> unlawful. Whilst reasonable efforts are made to ensure that any attachm= ents >>> are virus-free, it is the recipient's sole responsibility to scan all >>> attachments for viruses. All calls and emails to and from this company = may >>> be monitored and recorded for legitimate purposes relating to this >>> company's business. Any opinions expressed in this email (or in any >>> attachments) are those of the author and do not necessarily represent t= he >>> opinions of Moneyhub Financial Technology Limited or of any other group >>> company. >>> >>> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000000421e205b6815683 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5t= h Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2= =A0+44 (0)117 28= 0 5120

    =
    Moneyhub Enterprise is a trading style of Moneyhub F= inancial Technology Limited which is authorised and regulated by the Financ= ial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology= is entered on the Financial Services Register=C2=A0(FRN= =C2=A0809360) at https://register.fca.= org.uk/. Moneyhub=C2=A0Financial Technology is registe= red in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    Hi there
    Comments embedded=C2=A0
    = Thxs

    On Tue, Dec 15, 2020 at 2:58 PM Warren Parad <wparad@rhosys.ch> wrote:
    Beyond what we're covering here, I see at least o= ne important service that would directly benefit from tokens, around intros= pection/management api (e.g. is the token still valid?). Here there's n= o information lookup about a grant, we could just query a bloom filter if w= e get the authorization to do so. I agree it's not yet included but it&= #39;s perfectly feasible.=C2=A0
    I think we are so focused = on the "we can do this and this and thin with it" that we aren= 9;t thinking about why we need it. Instead of what can be done we sh= ould be thinking about, "what can't be done without it" or ev= en perhaps "With it we won't have to..."

    [FI] I guess we're all guilty of "why not&= quot; now and then. But in this specific case, the need is pretty clear and= directly related to the revocation features we've been discussing.=C2= =A0=C2=A0

    For instance, it's easy to construct an ar= gument against hypothetical value it could provide in cases that don't = exist yet. Equally vacuous arguments could be made for coupling to the futu= re apis/services endpoints when necessary as well as delaying adding the se= ssion token to the spec until after it is necessary.

    Plus the problem is not that you control the AS URI, it's= that you have only limited trust for what's in front of that. A bound = access token ensures that your call is anthenticated with the same key as b= efore, while the alternative doesn't.=C2=A0
    Could you = say more about the potential problem here, I'm not totally following.

    [FI] not a big= deal when people use a library, but otherwise end developers may just end = up copying the URI directly, not checking the TLD+1. With a basic stateless= URL, a simple compare is enough.=C2=A0=C2=A0

    = Conceptually, I like the idea to treat the continuation as another kind of = resource.=C2=A0
    Exactly, and why not. Further just as we c= an return arbitrary urls in the body of a request, why not utilize the hard= ened REST patterns and return them in for instance a Location header. By en= couraging custom responses having to reassemble future requests we are impl= icitly saying "We don't like any of the existing recommended patte= rns", and while it's totally okay to digress from them, we should = have a really good reason to do so.

    [FI] where did you see that we don't follow any = of the existing recommended patterns?=C2=A0

    <= br>
    =

    		<= p dir=3D"ltr" style=3D"line-height:1.2;border-left:1pt solid rgb(255,255,25= 5);border-right:1pt solid rgb(255,255,255);border-top:1pt solid rgb(255,255= ,255);margin-top:0pt;margin-bottom:0pt">Warren Parad

    Founder, CTO

    Secure your us= er data and complete your authorization architecture. Implement=C2=A0Authress.


    On Tue, Dec 15, 2020 at 1:53 PM Fabien Imbault <fabien.imbault@gmail.com<= /a>> wrote:
    <= div dir=3D"ltr">Ok, could you be more specific as to what you'd expect = for the persistent identifier ?
    Thanks
    Fabien

    =
    On Tue, De= c 15, 2020 at 1:50 PM Dave Tonge <dave.tonge@moneyhub.com> wrote:
    The persistent identif= ier=C2=A0is not a different issue, the current access token is used to reference an existing grant=C2=A0

    It may not be more di= fficult for a client to use an access token at the AS / RS. But ther= e=C2=A0is definitely an overhead on the client to manage=C2=A0this s= eparate access token.=C2=A0



    On Tue, 15 Dec 2020 at 12:10, Fabien Imbault = <fabien.im= bault@gmail.com> wrote:
    I think we always said the access token was= different, and handled as a bound token.

    But it doesn&#= 39;t mean it's more difficult for the client that already needs to be a= ble to handle tokens anyway (bearer or not, both cases could occur). It'= ;s mostly consolidating the logic.

    You're= anticipating a lot of issues which have no specific reason to occur, such = as "ca= n't be used with the token management APIs?". The management API i= s part of the same general flow.
    Anticipating issues with rotation is= useful, but there are also many ways it can be hard to manage through a st= ateful approach too. And fundamentally, having everything in a common model= (both for the internals of the AS and for the API calls) will help improve= by a large margin what is probably the weakest point in today's infras= tructure. But it's early to be definitive as to the downstream impact e= ither way.=C2=A0 =C2=A0

    As for a persistent identifier= instead of a continuation API, and generally the end of your message, it&#= 39;s a totally unrelated issue to this PR, so I suggest we don't discus= s that here, but in a separate issue if needed.

    =
    Fabien

    On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <dave.tonge@moneyhu= b.com> wrote:
    So we've established that this is a different access token, t= hat requires different handling at the client. So keeping it could cause mo= re confusion?

    As an RC, I will have to store the continue `uri` as although it could= be static it could also be dynamic. Why do I need to store an access token= as well.=C2=A0It brings me no benefit as an RC, in fact it brings more com= plexity. As I will now need to manage multiple types of tokens with differe= nt lifecycles:

    Continuation token=C2=A0
    =C2=A0 - can only be used at the continue en= dpoint (the name of which is confusing as I can use this endpoint to revoke= a grant or get metadata on the grant).
    =C2=A0- may be rotated each time it is use= d, or may not be
    =C2=A0- provided in the `continue` section of the response
    <= div style=3D"font-family:"trebuchet ms",sans-serif">=C2=A0- must = be sender-constrained
    =C2=A0- can't be used with the token management APIs?
    =C2=A0- c= an be used to identify the grant when making subsequent grants

    Access token(s) to= use at RS
    =C2=A0=C2=A0- can only be used at the specified RS
    =C2=A0 - may be = sender constrained
    =C2=A0 - when used at the RS, will not result in rotation
    =

    From my perspe= ctive, most use-cases will require the RC to have a persistent identifier f= or the grant. Why not bring this into the protocol and let the AS provide t= his persistent identifier (through the form of the continue uri). Using a r= otating access token as a persistent identifier doesn't seem like the r= ight choice.=C2=A0

    I see no security benefit to having the continuation access token= . It doesn't matter if the continue uri leaks as it is useless without = an accompanying signature, i.e. any security benefit of having an access to= ken is already provided by having a signature.

    The only benefits that I can see are:=
    =C2=A0= - If the AS wants to be fully stateless, then you can encode more data in a= token than in a uri
    =C2=A0- If the AS wants to have a static endpoint for CRUD op= erations on the grant
    =C2=A0- To allow the AS to identity a previous grant

    If we dropped th= e access token for the continue endpoint and rather mandated a dynamic uri = this would make things conceptually easier to understand, easier for the RC= to implement, easier to debug and less chance of errors when rotating toke= ns (i.e. race conditions could be quite likely if the AS always rotates the= token)

    <= b>One-off grant with no continuation or ongoing management:
    RC sends signature= and metadata, no `continue` response provided, therefore no grant manageme= nt possible

    Grant with ongoing management
    RC sends signature and metadata, AS respon= ds with a continue uri that has these purposes:
    =C2=A0- can be used by the RC to c= ontinue/update, read or revoke the grant
    =C2=A0- can be used by the RC when making= a new grant to identify the previous grant

    As an RC the only permanent items I need= to store are:
    =C2=A0- the continue uri associated with the grant
    =C2=A0- any access tok= ens I receive for the grant

    Dave

    On Tue, 15 Dec 2020 at 10:11, Fabien Imbault = <fabien.im= bault@gmail.com> wrote:
    Hi Torsten,=C2=A0

    You= 9;re right on both accounts.=C2=A0
    - for the first remark, it fit= s quite nicely the init request=C2=A0 / continuation pattern=C2=A0
    - for the second remark, it is a sort of handle for the continuation=C2= =A0request, which will eventually lead to the issuance or refresh of standa= rd access tokens=C2=A0

    Having a specific=C2=A0name= is a possibility, I actually suggested that too at some point.=C2=A0
    =

    Fabien

    On Tue, Dec 15, 2020 at 9:50 AM Torsten Lod= derstedt <t= orsten@lodderstedt.net> wrote:
    Hi Fabien,

    > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <fabien.imbault@gmail.com>:=
    >
    > Hi,
    >
    > On the contrary your feedback is most welcome.
    >
    > It doesn't accept any token, it needs the particular token as desc= ribed in 3.1 and which is not a bearer token (that's what the "key= " : true parameter is supposed to convey).
    >
    > Let us know if you need more clarifications.

    Thanks for the clarification. I think only accepting this kind of token at = the continuation is a good idea otherwise the AS would need to be able to p= arse and understand all sorts of access tokens.

    Conceptually, I like the idea to treat the continuation as another kind of = resource. However, here are some observations I want to share with you: - This resource is different as it will issue other access tokens (of this = kind) to be used in subsequent continuation requests. This requires differe= nt handing on the client side.
    - This access token (if I understand correctly) is (or at least feels like)= a handle for the underlying grant. So it is kind of the super access token= to obtain other access tokens.

    I would consider using a different term to refer to this special access tok= en, grant token or grant handle for example, in order to prevent confusion.=

    best regards,
    Torsten.


    >
    > Best
    > Fabien
    >
    > Le sam. 12 d=C3=A9c. 2020 =C3=A0 11:33, Torsten Lodderstedt <torsten@lodderstedt.= net> a =C3=A9crit :
    > Hi all,
    >
    > I didn=E2=80=99t follow GNAP closely so bear with me if me question se= ems naive.
    >
    > After having skimmed through the current draft and the PR, I=E2=80=98m= not sure whether the continuation requests accepts any access token issued= to the RC or the particular access token returned in the =E2=80=9Econtinue= =E2=80=9C element in section 3.1..
    >
    > Can you please shed some light on this?
    >
    > kind regards,
    > Torsten.
    >
    >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <fabien.imbault@gmail.com&= gt;:
    >>
    >> =EF=BB=BF
    >> You're completely right. Allowing the dev to be lazy is a very= good thing in general, because it's what we know will work :-)
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 03:15, Stephen Moore <srmoore@gmail.com> a= =C3=A9crit :
    >> Hi Fabien,
    >>
    >> For #3) Even after I typed out the hypothetical attack, that was s= ort of in the back of my mind, it isn't a huge risk there. So I actuall= y agree with Dick there. Something doesn't sit right with me for the un= ique URL solution, so I don't like it and came up with a hypothetical t= hat seems like it could be a down side.
    >>
    >> I still think the access token model with the signed request is th= e way I'd like to go, because again, it's a mechanism I'd be im= plementing anyway to talk to any 'normal' resource. The fact is the= re is _something_ representing context that has to pass back and forth here= , whether that is an access token (which I feel like is more flexible for e= xtensions etc), a unique url, or even a cookie sent in the cookie header. S= o just to re-iterate, I'm a +1 on this pull request, speaking as a lazy= developer ;)
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <fabien.imbault@gmail.com= > wrote:
    >> Again speaking in my own name here.
    >>
    >> Dick, we know you'd prefer to have a different design, but thi= s PR shouldn't be about that.
    >>
    >> Back on your 3 items :
    >>
    >> 1) yes we could make pre-register mandatory, but we already decide= d that wouldn't be how that would work. We have a client instance that = allows a more generic and flexible pattern (which BTW also allows what you = want)
    >>
    >> 2) instead of blame arguments of who's less restful/HATEOAS/wh= atever that have the tenancy to flame conversations, I suggest we speak in = less abstract terms and ask ourselves what that means in practice for devs.= Stephen and several others (myself included) have expressed that it wouldn= 't be harder to implement, it would even simplify things quite a lot. I= f you disagree please send us a code sample to really show that point by ex= ample, because that's really not obvious.
    >>
    >> 3) "If someone has the client credentials, they can impersona= te the client, and all bets are off." Are you seriously making this ar= gument? Because if you have a better proposal than using cryptographic keys= , I'm all hears. You make it look like there's a problem, while in = reality we're only relying on the basic assumption of all modern digita= l communications.
    >>=C2=A0
    >> And more importantly you never responded to the issues of how to a= void the security pitfalls of what you proposed.
    >>
    >> Fabien
    >>
    >>
    >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 00:35, Dick Hardt <dick.hardt@gmail.com>= a =C3=A9crit :
    >>
    >>
    >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> But from the spec:
    >> "
    >> When sending a non-continuation request to the AS, the RC MUST ide= ntify itself by including the client field of the request...
    >> ...
    >> key (object / string) : The public key of the RC to be used in thi= s request as described in {{request-key}}. This field is REQUIRED.
    >> ...
    >> "
    >> So on the initial request, the key will be there.
    >>
    >> The client field can be an object or a string. If the client is pr= e-registered, then a string could be provided instead of an object.
    >>=C2=A0
    >>
    >> If you don't have the access token, then how do you differenti= ate between two requests from the same web application by two different use= rs? Is the web application supposed to have different credentials for every= request?
    >>
    >> The AS returns a URI for manipulating the request. I would change = the spec so that each request would have a unique URI. This is the usually = RESTful pattern that the resource (the grant request) has an URI.
    >>
    >>=C2=A0
    >> So in this case, the easy way out is to pass the access token to t= he client, who then, as i stated before, treats the continue request as a R= S call (albeit a specialized version of the RS where the RS is the AS) OR t= o use the unique URL,
    >> but that seems open to a brute force attack by a malicious RC. (Wh= at would be the point of that attack, I don't know, I guess if someone = had the client credentials but not any subjects/resources they could try to= intercept the grant via continue... I just don't feel right locking th= ings down to unique URLs that way.)
    >>
    >> If someone has the client credentials, they can impersonate the cl= ient, and all bets are off.
    >>
    >> LOTS of RS servers return a resource specific URL -- my proposal i= s no different.
    >>
    >>
    >>=C2=A0
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> Hi Stephen
    >>
    >> The client is signing the first request. The key *might* be in the= body. The client is signing all the subsequent requests as well. The "= ;access token" is not needed by the client to prove it is authorized a= s the client is proving it is the same client again.
    >>
    >> In other words, I don't see the need for an access token, so i= t does not need to be put in a URL or an auth header.
    >>
    >> If a developer really, really wants to hand context back to the cl= ient for subsequent calls, they can put it in the URL or some other method.= Putting it in the HTTP Authorization header is confusing because it is NOT= an access token -- it is the context of the request.
    >>
    >> =E1=90=A7
    >>
    >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <srmoore@gmail.com> wrote:
    >> Even though I've only been lightly following things, I feel th= e need to voice my preference as a developer since I will probably someday = have to either write a RC or RS...
    >>
    >> The way I see it is the RC makes the initial request to the AS as = part of this request, it provides it's key in the body... (So no use of= the Authorization header)
    >> At this point that request, represented by the continue URL + &quo= t;Access Token", from my lazy developer standpoint, is a Resource Endp= oint and Access Token, and the AS is acting as a specialized RS in this cas= e.
    >> So my client posts to whatever URL with the 'access token'= in the authorization header, just like acting on any other resource I have= a token for. YES, I get a new token value to use every call, and there is = a decision point of "Do I have another continue, or do I have a real t= oken for the resource..." But the mechanism is the same to me in the c= lient.
    >> Personally I like that, because if I have an access_token, I alrea= dy think "Put it in the auth header."
    >>
    >> So my vote would be +1 for the pull request at this time.
    >> -steve
    >>
    >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >> inline ...
    >>
    >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <jricher@mit.edu> wrote:
    >> Others had already responded to this previous thread, but I wanted= to add a couple points to clarify some things.
    >>
    >>> 3) What the client has to do with the "access token"= is not the same as access tokens for an RS. The client gets a new "ac= cess token" for each grant request, and for each API call to the AS, a= nd the client learns it can not make any more API calls for that specific r= equest when it does not get an "access token" back. This is a com= pletely different design pattern than calling an RS API with an access toke= n, and is a new design pattern for calling APIs. This adds complexity to th= e client that it would not normally have, and I don't think GNAP is the= right place to start a new design pattern.
    >>>
    >>
    >> I=E2=80=99m not sure what you mean by these being different =E2=80= =94 the whole point of the design is that the client would be doing the sam= e thing with the access token at the AS that it does with the RS by re-usin= g the access token structure. Can you please describe what the differences = are, apart from the rotation? Presentation of the token and signing of the = message are identical.
    >>
    >> The client is getting the "access token" from its API. I= t is not using an "access_token" in other API calls to the AS. >>=C2=A0
    >>
    >> Rotation of the access token and artifacts for ongoing continuatio= n responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 >>
    >> And for what it=E2=80=99s worth, GNAP is absolutely the right plac= e to have new designs =E2=80=94 not that this is one.
    >>
    >> You are proposing a new way for an API to provide context for subs= equent API calls. Looks out of scope to me.
    >>=C2=A0
    >>
    >>> 4) Clients that only want claims from the AS and no access tok= ens will be required to support an API calling mechanism they would not hav= e to support otherwise.
    >>
    >> Correct, but the delta between the calls a client would make with = and without an access token is vanishingly small. The client has to sign th= e initial request in some fashion, and it will sign the continuation reques= t in the same exact fashion, but now include an access token in that reques= t.
    >>
    >> Per my other point, there is no value to me in my implementations = of passing context back and forth between the client and AS -- so it is ext= ra work providing no value.
    >>
    >> Also, any client authentication mechanism that wants to use the HT= TP Authentication header is precluded from using it.
    >>
    >>=C2=A0
    >>
    >> Clients making a request to an AS and not getting an access token = is a new design pattern. I think it has value and should be included, but O= Auth today shows us the immense value of getting access tokens for calling = APIs, and so we shouldn=E2=80=99t optimize away from that pattern.
    >>
    >>>
    >>> 5) If the AS does not provide an "access token", the= re is no mechanism for a client to delete the request, as the client is not= allowed to make a call without an "access token".
    >>
    >> More properly, if the AS does not provide a =E2=80=9Ccontinue=E2= =80=9D field then the client can=E2=80=99t delete the request =E2=80=94 and= yes, that=E2=80=99s intentional. The AS is telling this client instance th= at it can=E2=80=99t do anything else with this ongoing request. If the AS w= ants to allow the client to manage it, it will include the mechanisms to do= so in the =E2=80=9Ccontinue=E2=80=9D field.
    >>
    >> There is nuance in that intention. A related concern is that delet= ing a request does not seem like it is a "continue" operation. >>=C2=A0
    >>
    >>>
    >>> 6) There is no standard identifier for the request. Debugging = and auditing are hampered by the client and AS having no standard way to id= entifying a request. While one AS may provide a unique URL for each grant r= equest, another AS may use a persistent "access token" to identif= y the grant request, and other ASs may issue a new "access token"= on each API call, providing no persistent identifier for the request.
    >>
    >> Debugging and auditing this kind of thing are functions of the AS.= How is interoperability harmed by different ASs having different methods t= o identify their internal data elements? The client doesn=E2=80=99t need an= y knowledge of the AS=E2=80=99s identifiers, it just needs to know the next= steps for continuing the negotiation.
    >>
    >> Debugging between the client and the AS was what I was referring t= o. How does a client developer identify the request when communicating to t= he AS developer. Seems complicated.
    >>=C2=A0
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >> TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> =E1=90=A7
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> https://www.ietf.org/mailman/listinfo/txauth
    >> --
    >> TXAuth mailing list
    >>     TXAuth@ietf.o= rg
    >> h= ttps://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/txauth&= amp;source=3Dgmail-imap&ust=3D1608345320000000&usg=3DAOvVaw0r39lH4q= VOu0IQPJJYtSpI

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


    --
    Dave Tonge
    CTO
    3D"Moneyhub
    Moneyhub Financial Technology, 5t= h Floor, 10 Temple Back, Bristol, BS1 6FL
    t:=C2= =A0+44 (0)117 28= 0 5120

    =
    Moneyhub Enterprise is a trading style of Moneyhub F= inancial Technology Limited which is authorised and regulated by the Financ= ial Conduct Authority ("FCA").=C2=A0Moneyhub Financial Technology= is entered on the Financial Services Register=C2=A0(FRN= =C2=A0809360) at https://register.fca.= org.uk/. Moneyhub=C2=A0Financial Technology is registe= red in England & Wales, company registration number=C2=A0=C2=A006909772= =C2=A0.
    Moneyhub=C2=A0Financial Technology Limited 2019=C2=A0=C2=A9

    DISCLAIMER: This email = (including any attachments) is subject to copyright, and the information in= it is confidential. Use of this email or of any information in it other th= an by the addressee is unauthorised and unlawful. Whilst reasonable efforts= are made to ensure that any attachments are virus-free, it is the recipien= t's sole responsibility to scan all attachments for viruses. All calls = and emails to and from this company may be monitored and recorded for legit= imate purposes relating to this company's business. Any opinions expres= sed in this email (or in any attachments) are those of the author and do no= t necessarily represent the opinions of Moneyhub Financial Technology Limit= ed or of any other group company.

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

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


    Hi Fabien,=

     

    =E2=80=9CTypically=E2= =80=9D means =E2=80=9Cusually, though there may be fully public resources where some o= perations don=E2=80=99t require any authorization, but I don=E2=80=99t want a normative = statement in the Terminology section=E2=80=A6=E2=80=9D

    =  

    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

    <= o:p> 

    From: F= abien Imbault <fabien.imbault@gmail.com>
    Date: Sunday, Decem= ber 13, 2020 at 21:21
    To: Yaron Sheffer <yaronf.ietf@gmail.com&= gt;
    Cc: Denis <denis.ietf@free.fr>, GNAP Mailing List <tx= auth@ietf.org>
    Subject: Re: [GNAP] Terminology proposal

     

    =

    Hi Yaron, 

     

    Stylistic comments are = very important too. And at some point we'll need a review from native englis= h speakers in the group (I'm sure Justin and Aaron will be of great&nbs= p;help here).

     <= /p>

    Just wondering: what do you mean by "t= ypically"? (ideally I'd rather have a definition which is not dependent= on use case).

     =

    As soon as we land on something, I'll upda= te the wiki.

     

    Fabien

     

     <= /p>

     

    On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    It=E2=80=99s purely= stylistic, but I find the definition of RS (=E2=80=9Cserver that denies operation= s=E2=80=9D) a bit funny. How about:

     

    Resource Server (RS)

    Hello everyone, 

     

    We're at the end of the 2 week period= , and so I integrated the various feedbacks : 

     

    a) from Yaron's feedback, removed new t= erm "IS" and update issue https://github.com/ietf= -wg-gnap/gnap-core-protocol/issues/133 to handle the proposal here =

    b) integrated Tom's feedback regarding the RO (a= nd moved  to access token)

    c) definitions fo= llow an ISO style as suggested by Denis, which we took as a starting point (= but I made the modifications I felt were necessary)

     

    I modified the definitions, notes = and examples as a consequence. You'll also find a summary of discussions for= each term, so that we can keep track of them too.

    =

     

    My biggest question is : what should we = use as our main vocabulary between privilege/rights/attribute? I tried to cl= arify, please let me know what you think. The general idea is that we grant = privileges that are delivered under the form of access tokens (which contain= rights and/or attributes).

    Regarding whether acc= ess tokens should be opaque or not, I suggest to remove that from the defini= tion and handle that in issue https://github.com/ietf-wg-gn= ap/gnap-core-protocol/issues/145

     <= /o:p>

    All has been consolidated on the wiki too https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminolo= gy so that we have a clearer view of where we stand. 

     

    Please comment further on th= e list if you have comments, I'll update if necessary (and refer to the= mailing list url in the comment of the wiki update, from now on). Then edit= ors will review the proposal. 

     

    Latest discussion update

    Here we consolidate the l= atest proposal(s) from the group. We also include the discussion items (indi= vidual feedbacks).

    Authorization Server (AS)

    • Definition: server that grants p= rivileges to a particular end-user and that provides them to a client in the= form of an access token

    Feedbacks / discussion / questions :

    • Suggested "privilege" definition (that we would probably a= dd as an additional sub-entry): "A privilege is the right to perform an= operation (or action) on a Resource." See also other def
    • Note that we don't include claims in the defi= nition (cf OIDC/SSI integration), but since we talk about a "particular= end-user" it is assumed somehow
    • Denis suggested we used "rights and attri= butes" instead of privileges. [FI] However i don't think one can really= speak about granting attributes, except indirectly (ABAC). See access token= for more on that, where we can be more specific.
    • Do we allow cases such as distribu= ting the AS on a mobile? (in this case we're at the limit of what we call a = server)

    = Client

    • Definition: application used by an end-user to interact w= ith an AS or a RS
    • Note: this specification differentiates between a specific instance= (the client instance, identified by its public key) and the software runnin= g the instance (the client software). For some kinds of client software, the= re could be many instances of a single piece of client software.=
    • Example: a client ca= n be a mobile application, a web application, etc.

      • Feedbacks / disc= ussion :

      • Replaces previously proposed RC, we wouldn't provide a= short name.
      • Keep OAuth2 term, but we clarify it
      • Further discussion on Client= instance

      Resource Server (RS)

      • Definition: server that denies operat= ions on protected resources, unless the client provides valid access tokens = issued by an AS

      Feedbacks / discussion :

      • Denis suggests= to make explicit that we could have several ASs - "issued by one or mo= re ASs" (also we'd need a convention on how to denote plural, e.g. ASs)= . Not exactly sure right now of the multiple issuance would work, so needs t= o be clarified. Also not sure if that's even necessary (do we lack in genera= lity if we keep the singular?)

      Resource Owner (RO)

      • Definition: physical = person acting on its own or representing an organization, that may grant pri= vileges on resources he has authority upon
      • Note: the act of granting privileges may b= e manual (i.e. through an interaction) or automatic (i.e. through predefined= rules).

      Feedbacks / discussion

      • As some point we sugges= ted "The RO may decide to remove its consent at any time." Tom pro= vided useful feedback on that. Moved t= o access token where it fits more naturally.

      End-user

      • Definition: physi= cal person that operates with the client software
      • Note: that physical person may or = may not be the same entity as the RO

      Access token

      • Definition: digitally= signed data that contains specific rights and/or attributes
      • Note 1: the access toke= n can be issued to an end-user (usually requiring his authentication) and su= bsequently refreshed. The AS usually provides a method for the RO to revoke = the privileges at any point in time.
      • Note 2: an access token may act as a capability= (i.e. bearer token) or require an additional authentication by binding to a= key (i.e. bound token)

      Feedbacks / discussion
      • Would = require the subdefinitions right: ability for an end-user to perform a given= operation (or action) on a resource (or object) under the control of a RS /= attribute: property related to an end-user.
      • Note 2 is here in relationship with&nb= sp;PR 129

      Grant

      • Definition (verb): to permit, as a privi= lege given to an end-user to exercise some rights and/or assert attributes d= uring a specific duration
      • Definition (noun): the act of granting<= /li>

      Key

      =
      • Definitio= n: public cryptographic binding a request to the holder of a private key, us= ed by the protocol entities (AS, RS, client instance, bound token, etc.) to = identify themselves.
      • Note: a key can be rotated or revoked by its holder. The protoc= ol supports the update of the key information.
      Feedbacks / discussi= on

      • Denis thinks the term "key" is well understood an= d doesn't need to be defined. Yet, I tend to believe we'd gain to keep it. F= irst the generic term "key" may be many things : symmetric/asymmet= ric, public/private, etc. It's also useful to explain its use in the protoco= l

      Resour= ce

      • Definition: protected API served by a RS and accessed by a c= lient, if and only if a valid access token is provided

     

    On Fri, Dec 11, 2020 at= 6:05 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Yaron, 

     

    <= div>

    Yes I highlighted that this was a new term. We can deal with it as a s= eparate issue indeed. 

     

    =

    Best

    Fabien

     

    On Fri, Dec 11, 2020 at 6:02 PM Yaron S= heffer <yaronf.iet= f@gmail.com> wrote:

    Hi Fabi= en,

     

    Yes, we definitely need to reach = closure on terminology, thank you for driving this discussion!

     

    One process comment: unless I=E2=80=99m missing somethin= g, the Interact (or Interaction) Server is not mentioned in the current draf= t. I suggest we do not introduce new functional components or new behaviors = as part of the terminology discussion. Specifically, if the IS is useful, le= t=E2=80=99s reach consensus on that separately. Then we can add it into the Termin= ology section.

     

    Thanks,

    =

                &n= bsp;   Yaron

     

    From: TXAuth <txauth-bounces@ietf.org> on behalf of Fabien Imbault &l= t;fabien.imbault@g= mail.com>
    Date: Friday, December 11, 2020 at 14:31
    To= : Denis <denis.ie= tf@free.fr>
    Cc: GNAP Mailing List <txauth@ietf.org>
    Subject: Re: [= GNAP] Terminology proposal

     

    Hi Denis, 

     

    Thanks for your detailed feedback. My comments are embedd= ed into your message. Again those comments are my own, and we'll need to con= verge to some consensus beyond what I say here. My main open question is rea= lly about the RO being optional. Could you explain?

     

    Fabien 

    =

     

    On Fri, Dec 11, 2020 at 12:08 PM Denis &l= t;denis.ietf@free.fr= > wrote:

    This is a global respo= nse to the definitions proposal.

     

    Terminology=

    I propose to adopt the= way ISO defines how to write the definitions.

    It is a single sentence<= /span> that may be substituted to the wording being d= efined in the context of a sentence that uses that definition.
    Since thi= s single sentence can be substituted to the wording, there is not point at t= he end of that sentence. The sentence does not
    have a "a" or &= quot;the" in front of it.

     

    [FI] = ;In the first version, I was mostly trying to not get too far away from the = current text. But yes that's a good idea, it gives a more formal rule, which has= been proven to work. 

    <= h3 style=3D'margin-bottom:0in'> 

    If more information is = useful to understand the wording, it is placed in one or more notes afterwar= ds.

     

    Note: The I= SO rules for drafting definitions are in the ISO/IEC Directives, Part 2 (edi= tion 2018):

    16.5.6    Definitions

    The defin= ition shall be written in such a form that it can replace the term in its co= ntext. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end with = a full stop.
    A definition shall not take the form of, or contain, a requ= irement.

    Only one definition per terminological entry is allowed. If = a term is used to define more than one concept, a separate terminological en= try shall be created
    for each concept and the domain shall be included i= n angle brackets before the definition.

    Circular definitions, which r= epeat the term being defined, are not allowed.

    Comments are inserte= d between the lines.

     

    =

    Hello = everyone, 

     

    As a= n editor : a quick reminder that terminology issues will be discussed i= n the coming weeks, and we're expecting your inputs right now (according to = the process previously sent on the mailing list).

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29=

    &= nbsp;

    The rest of this message is a proposal writ= ten in my own name, and doesn't involve discussions with the editors/chairs = who might have different opinions. 

    Authorization Ser= ver (AS)

    Manages the = granting of privileges to a third-party client instance. If the RO consents = to at least a part of what is requested, the AS issues an access token to th= e client.

    My quest= ions:

    - was el= se do we issue? (e.g. id claims, payment info, etc.) We could have more than= access tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I removed that = for now.

    - ther= e might potentially be several AS, currently we don=E2=80=99t reflect that anywher= e. If would leave that as an open item, depending on what we end up doing in= the spec

    I am= not in favour of this definition: A RO as defined later: "authorizes t= he request to access a protected resource from the RS to the client". <= br>This does not mean in any way that a RO has necessarily a direct relation= ship with one or more ASs. [FI] indeed we could remove that limitation, to have a more gen= eral definition

    Usin= g the ISO style for definitions, I propose:

    = Authorization Ser= ver (AS): server that grants rights and/or attributes to a particular end-us= er and that provides them to a client in the form of an access token<= o:p>

    Since this definition is using the words "rights" and "attributes", these two t= erms need to be defined as well.

    right: ability for an end-user to pe= rform a given operation on an object under the control of a RS

    attribute: property related to an end-user

     

    [FI] I like your proposal in general. There might be some dis= cussions on the details. I don't think it makes sense to grant "attribu= tes".   

    Some ex= planations: a "right" is able to support a capability scheme. An &= quot;attribute" is able to support an ACL scheme.

    T= hese two schemes are able to support "discretionary access control"= ; where the end-user has a "need-to-know".

    <= p style=3D'margin-bottom:0in'>How= ever, some attributes are also able to support what  was called in the = past "mandatory access control"; for example,

    = if the end-user is cleared to "top-secret / marketing strategy".

     

    Interact Server (IS) - this is a new proposed term=

    Manages the front-end i= nteraction with the RO, in order to gather its consent. Depending on the dep= loyment model and the privacy requirements,
    the IS may be a component of= the AS, or may be distinct and managed by another party.    <= /p>

    Example : an IS usually involves a web inte= rface accessed by RO through a web browser.

    Note : an IS is not always required, especially if the a= ccess is granted through automated policies.

    Using the ISO style for definitions, I propose= :

     

    Interaction= Server (IS)

    component from the AS or server interfacing with an= AS that manages the interactions with a RO, in order to gather its authoriz= ation

    Note : since = the RO is an optional component, the IS is also an optional component.

     

    [FI] indeed IS is optional. note for m= yself when looking at RO : why is RO optional ?  

    Client

    Requests privileges from the AS, and uses access tokens at = the RS. This specification differentiates between a specific instance (the c= lient instance, identified by its unique public key)
    and the software ru= nning the instance (the client software). . For some kinds of client softwar= e, there could be many instances of a single piece of client software.
    Th= e AS determines which policies apply to a given client instance, including w= hat it can request and on whose behalf.

    Some comments: The above text = is stating: "(the client instance, identifi= ed by its unique public key)".
    A client instance may use a public k= ey, but that key is not necessarily unique, in particular when there are mul= tiple ASs.

    [FI] yes, although when possible I would still consider a bett= er practice to expose a key to a specific AS and not to the entire set of av= ailable ASs. 

    Example : a client can be a mobile application or a web application= (the client software) that requires authorizations from the RO to retrieve = content from various protected APIs. The client instance may for instance re= fer to a specific version of that client software.

    See on-going discussion : https://github.com/ietf-w= g-gnap/gnap-core-protocol/pull/132 (client instance).

    Using th= e ISO style for definitions, I propose:

    Client: application used by an end-user to interact with an AS or a RS

    Note: a client can be a mobile application or a web= application [= FI] for me those are just examples, because there could me more (ex IoT devi= ce)

    [FI] you remove the entire discussion on client instance / clien= t software, is that on purpose because you think it's not useful/right, or i= s it because of something else? (maybe add your comment of the related issue= )   

    Resource Server (RS)

    Accepts valid access tokens from the= client issued by the AS and serves protected resources on behalf of the RO.= There could be multiple RSs protected by the AS that the client may call.

    Example : a RS is often= composed of protected APIs that can be consumed by authorized client softwa= re. 

    One com= ment: a RO is not necessarily involved. [FI] a bit hard to imagine, there's some kind of o= wner. Could you be more explicit?

    Using the ISO style for definitions, I propose:

    Resource Server (RS): server that accepts valid access tokens from clients = issued by one or more ASs which are used to grant or deny some requested ope= rations

    Note: a RS is often composed of pro= tected APIs that can be consumed by clients.

    &= nbsp;

    Resource Owner (RO)

    Authorizes the request to access a protected resource from the RS to the c= lient. The RO may decide to remove its consent at any time.

    Note : the RO may be a physical person= or may represent an organization.

     

    Two comments: In order to avoid conf= usion with the end-user consent, the word " authorization" is bein= g used instead of "consent". [FI] ok 

    It s= hould be said that the RO is an optional component. [F= I] why? Using the ISO style for definitions, I propose:

    Resource Owner (RO): physical person acting on its own or representing an o= rganization that authorizes to clients operations on protected resources fro= m a RS

    Note: The RO is an optional componen= t that may interact either with one RS or with one or more ASs ,e.g. using a= n IS.

    End-user <= /span>=E2=80=93 this was previously Requesting= Party RQ

    A physical = person that operates and interacts with the client software.

    Note : the end-user may or may not b= e the same entity as the RO.

    =

    Th= e Note is slightly incorrect. the physical pe= rson may or may not be the same entit= y as the RO. [FI] I didn't understand your co= mment

    Using t= he ISO style for definitions, I propose:

    End-user :  physical person that operates and interact= s with the client software

    Note : = that physical person may or may not be the same entity as the RO.

     

    Access Token

    A set of privileges delegated to the client inst= ance for a specific end-user. An access token is created by the AS, consumed= and verified by the RS, and issued to and carried by the client's end-user = on behalf of the RO. The contents and format of the access token are opaque = to the client.

    Example= : JWT is a commonly used format.

    Note 1 : an access token generally has a limited duration, afte= r which it may be refreshed at a regular interval.

    Note 2 : an access token may be revoked at any = time by the RO.

    Note 3 : an access = token may act as a capability or require an additional authentication by bin= ding to a key

    A fundamental poi= nt: the third sentence from the definition states: "The contents and format of the access token are opaque to the clien= t".

    [FI] I'll check your other thread dedicated to that issue 

    See my other email sent today about &= quot;RS-Token Introspection or RC-Token Introspection" where I conclude= :

          For end-users caring abo= ut their privacy (or for systems willing to protect the user's privacy), acc= ess tokens should not be considered
          to be opaque to RCs nor to RSs= and ASs should not support Token Introspection, whether it is RS-Token Intr= ospection or RC-Token Introspection.

    The example and the other Notes above should b= e removed. If needed they should be placed in the main body of the document.=

    Using the ISO style for definitions, I propose: =

    Acc= ess Token : digitally si= gned data issued by an Authorization Server (AS) and consumed by a Resource = Server (RS)
              =             &nbs= p;  that contains rights and/or attributes = granted to a particular end-user

    =  

    Grant

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

    Using the ISO style for definition= s, I propose:

    Grant: permission given to end-user to use a subset of hi= s rights and/or his attributes at a specific time and for a specific duratio= n

     

    Key

    A public cryptographic binding a request to the holder of a priv= ate key. Access tokens and client instances can be associated with specific = keys at a point in time.

    Note : a key can be rotated or revoked by its holder. The protocol suppo= rts the update of the key information.

    "key" is a general term that is well underst= ood and that does not need to be defined. [FI] I really wouldn't bet on that. We can reuse= an existing definition but it is a central piece so we need to be explicit<= /span>

    The "definitions" section is not = intended to explain what can be done with the term that is being defined. [FI] ok we can w= ork on that
    Until the word "key" is qualified using one or = more other terms, this definition should be removed.

     

    Resource

    A prote= cted API served by the RS and accessed by the client if and only if access h= as been granted. Access to this resource is delegated by the RO as part of t= he grant process.

    = The second sentence of the definition is not in accordance with the ISO styl= e or definitions and furthermore this second sentence should be removed sinc= e a RO is an optional element.

     

    Using the ISO style for definitions, I = propose:

    Resource: protected API served by a RS= and accessed by a client, if and only if access is granted by an access tok= en

    Subject Information

    Info= rmation about a subject (usually a RO) that is returned directly to the clie= nt from the AS.

    Note : thi= s information needs to be unique.

     

    This definition exhibits several problems:

    (1) The term "subject&quo= t; is not defined.

    (2) The information that is returned = is for an end-user, i.e. not for "(usually a RO)".

    (3) The Note states : "this information needs to be unique= ". Does it mean unique for the AS ? globally unique ?

    This definition should be revisited. [FI] I agree (I myself = had many questions here)

    Denis

     

    My questions :

    - probably we=E2=80=99d need to define subject

    Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subject+D= ictionary+Entry

    - might be useful to clarify the relationship to what identity providers do=  

     

     

    Cheer= s

    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/lis= tinfo/txauth

    =
    this is not an a= ct but an artifact of an act

    Peace ..tom
    --000000000000326fd405b65c6bb7-- From nobody Sun Dec 13 10:11:38 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA473A08E7 for ; Sun, 13 Dec 2020 10:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Hf6x8U8DFUv3 for ; Sun, 13 Dec 2020 10:11:36 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC1F3A08D6 for ; Sun, 13 Dec 2020 10:11:36 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id d189so16589391oig.11 for ; Sun, 13 Dec 2020 10:11:36 -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=/EWZoQEaoU2AsU/KEWmlViaBckUMMFY1Gf9JWWJss98=; b=DMkQOVoDLp3P35f615tZ9wEvICb/K84XYta5CcAg19g5ewl4fR0xpAkKkNzZCZCVpC uom50lU8hRl07L5fFHHYpLbdArng2UnsbYfeR9VtT5eRKnh7MOk6SlViYRlmX4PG5gF7 zBp3krSVbJx3yTm948qKN8IuyenlVSCMg2rO8E8QtJM+Hb/MvMB8asPmmQAeFUS0Qmap EFyIgRcPQtpy+ZMFZq1YYZlb8s9mic4/ejCNp7haM9EtxjFFXBMXf62M5uJili3yr4sh QduxN5PDriNwelqQ3c88zE3jcNoqt6a8Bf0gP48lVem0wxYLStxWpDaDMsFW3ud9sTiz uKfQ== 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=/EWZoQEaoU2AsU/KEWmlViaBckUMMFY1Gf9JWWJss98=; b=Gj4cEqhuDe837ltiFl1SKpO4tBx9IZ7huvbPCPSbjupL7ikH8bX4DyTKRKxeVViBen QIDBBICeKW3LnHjlaVK0ZN25KRN9svzX/WINe1vLVI2CscQ9HgraL0YNcbNsa675ZkCs ouAnjx7vyHsR4fzEeh4TGzkYzJ7W8tcDUN5XhgzrfOTEg9lvSkHjkiNlhMPXQe1TTNTM RjsbVsFKtUGWKM3fTPlTp/qDjAWu0AvXdD+EN9tZ/G3oVTXi1qJbAbnwsbzpEl38I2be Y8SUsQRO6OSUng0f03+FqrmUF1By989gfqqK5oSCaHMKdYrgJHovX7OWZv4t/1h53vOI Y1Uw== X-Gm-Message-State: AOAM532NYFhVCxdO2zydbCOnmJAbpRNAwqqf7YKE6zMbYDqS+ndS2NDE LZqiBEjaU1ROJAvv8uHzF2rA+HuUEoBe2tAJ2gYQodFGzSA= X-Google-Smtp-Source: ABdhPJyKuQ3v0P5PwgDHVnSempXOpEY9stm5fn8jdmp1X8Ei2AVniYQsZ27ORD1nc2viv+zU7Lst2BWH/HiRyCvxa7Y= X-Received: by 2002:aca:470e:: with SMTP id u14mr15523330oia.172.1607883095020; Sun, 13 Dec 2020 10:11:35 -0800 (PST) MIME-Version: 1.0 From: Tom Jones Date: Sun, 13 Dec 2020 10:11:23 -0800 Message-ID: To: txauth gnap Content-Type: multipart/alternative; boundary="000000000000b816f805b65c74ba" Archived-At: Subject: [GNAP] notes about what the standard does (eg key) 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, 13 Dec 2020 18:11:37 -0000 --000000000000b816f805b65c74ba Content-Type: text/plain; charset="UTF-8" do not belong in the terminology but in a normative section or the introduction. Peace ..tom --000000000000b816f805b65c74ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    do not belong in the terminology but in a normative sectio= n or the introduction.

    = Peace ..tom
    --000000000000b816f805b65c74ba-- From nobody Sun Dec 13 10:43:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E0B3A0994 for ; Sun, 13 Dec 2020 10:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=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 PEZ97rrrDIl5 for ; Sun, 13 Dec 2020 10:42:59 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5AE3A0992 for ; Sun, 13 Dec 2020 10:42:59 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id z5so14767508iob.11 for ; Sun, 13 Dec 2020 10:42:59 -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=VBlBF9ah4zY7ukdY23tRCzDLkt+8lUzINWej0ZoY0JQ=; b=k04RJT63bmUAwZEG7JJe1MssO9LD3ioUjzXAAeN5uMuvauYG/I9zx3RREtZFQ9QYKa IRJUmfvzaiHKZ9Pugp8/sb8XuC2/hVFiAxYg/RvWvaKEackacsxowRdJfiJWnubgBpLq urSsobNp0P+OQzIGJegWvIBpVJbTSttF8gUxaqjSvJ6Fzb/zseEtYYmTLaIVA50umYlO tOohjBn04w86viNkUdlVWjczYz6G1RMPHk0HyzEwT/Gp2p65KU+VTJtT+x4/5VNR3gV6 c4ZWtit76kd2raEIc3614UHmTKVWE4AodTDdZhAo7uW3X1GGdcOTNerlTvnttTeC+fnv LG/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VBlBF9ah4zY7ukdY23tRCzDLkt+8lUzINWej0ZoY0JQ=; b=Nl3Y5E7N/FJa0HiaiikgiAMrtxFNm9tBfPY3DLY9anNXdhw1q84E00Wu/w0oACdwnF CZROZ5NrfTBZQIwcPYHRZxhc27q9b5CfgNkiA2quSm7eb7Q8RFxv6Sppc5QqxTM6hH3Z 21MZju6VZPAg1Db/bTHh9cykEVcLXI7f9w5j5UEy7AsXCaf33OZ7VqXFB4UXfyKy6BZi 34rCCHfeiXtXk6Gv7SGq2yokIfgGzdSUgyR3HLOUgGeaREu1Uv1FgGmm4xFrhXJCkMx6 ApD/XY+odUuNIjpMOhhkCuUeGZosWFtFJlClYwCy4NFN+kEmy/OCvKIpeBOj4viWxeR2 l1cg== X-Gm-Message-State: AOAM530RfQ+4ZfvFdXf2YKeZAkV0IIkl4leox9WRnPiOJVEiPR/afewz h+OVtw0XMDsirBXOiPxDU4QVb63itN0HaVdGyns= X-Google-Smtp-Source: ABdhPJyAeLTecZJ4FcfMTU1yUFgsREkxp/beaS7h+QHRDlP6/u9h+8kcm5lYt3Gj/EvgvKFVnZTWesWKRj7YxMpAzyw= X-Received: by 2002:a5e:a916:: with SMTP id c22mr27020682iod.144.1607884978666; Sun, 13 Dec 2020 10:42:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sun, 13 Dec 2020 19:42:47 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="000000000000fe3f6c05b65ce479" Archived-At: Subject: Re: [GNAP] client definition 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, 13 Dec 2020 18:43:01 -0000 --000000000000fe3f6c05b65ce479 Content-Type: text/plain; charset="UTF-8" Hi, Thanks for the feedback. Highly use case specific seems a bit of an overstatement, I would say it is the most common case. But I get your point. We've tried to be more specific on end-user vs RO. In your proposal I guess the user you're referring to is the RO. I find the suggested definition a bit convoluted, let's think about it a bit more. Cheers Fabien On Sun, Dec 13, 2020 at 7:04 PM Tom Jones wrote: > This definition is highly use case specific. It leaves out the possibility > of (eg) a self-issued identifier where the RP displays a request to the > user on a web page, the user clicks the button and the result is that a > wallet on the user's device acting as the AS sends an access token to the > RP (which is typically the client in an OAUTH sense.) The underlined part > is often incorrect. > > Client > > - Definition: application *used by an end-user* to interact with an AS > or a RS > > suggestion: Client, an application that desires to get access privileges > from a user to resources on an RS, possibly by way of an AS. > > Peace ..tom > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fe3f6c05b65ce479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    Thanks for the feedback. High= ly use case specific seems a bit of an overstatement, I would say it is the= =C2=A0most common case. But I get your point.
    We've tried to = be more specific on end-user=C2=A0vs RO. In your proposal I guess the user = you're referring to is the RO.=C2=A0

    I find th= e suggested definition a bit convoluted, let's think about it a bit mor= e.=C2=A0

    Cheers
    Fabien


    On Sun, Dec 13, 2020 at 7:04 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    =
    This def= inition is highly use case specific. It leaves out the possibility of (eg) = a self-issued identifier where the RP displays a request to the user on a w= eb page, the user clicks the button and the result is that a wallet on the = user's device acting as the AS sends an access token to the RP (which i= s typically the client in an OAUTH sense.) The underlined part is often inc= orrect.

    Cli= ent

    • Definition: application used by an end-user to interact with = an AS or a RS
    suggestion: Client, an applicatio= n that desires to get access privileges from a user to resources on an RS, = possibly by way of an AS.

    =
    Peace ..tom
    <= /div>
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000fe3f6c05b65ce479-- From nobody Sun Dec 13 10:44:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE03A097E for ; Sun, 13 Dec 2020 10:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cageDo356zqO for ; Sun, 13 Dec 2020 10:44:00 -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 66F693A097C for ; Sun, 13 Dec 2020 10:44:00 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id y5so14770573iow.5 for ; Sun, 13 Dec 2020 10:44:00 -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=Sk78d+DRvkcqg3n2QBG987+wNAdfGRnVcAAaLiDbmMg=; b=a945ei8jb4mmS1Sc4ib9dOfehppqCfru8O4EU91SKTSo3LiT3Ye/C6JwTckSo8GSfp av66DDUokCQUyyeQVaC+oceADkAlpYlytxhzwTWhQxFIl+ww49kb61VoByRPeyb+72Ap Iy+KPF2XP32TjnjRsJy8Spp4zih90rrRci/CNHxpu8F9gK6DIQ7i7W5fdvwC5nQBnIb3 M8d6Mv4gLwl7Ctq0B7qtom1VPOq/xDF8Jhd1JGRWFkY6jYKZsbKFoK+rxOSh5dTZ1Tdc dhDcL3vuD33U2413tX2HpW0pSUm0T+H8wEdi1CEDEPw4JHhp5gDu4rNtzfin1rOtXbsl inng== 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=Sk78d+DRvkcqg3n2QBG987+wNAdfGRnVcAAaLiDbmMg=; b=qGFZ+ABEunCoWfZeblVHtUf4H0VKnI0DWzZxageqa27zBQCW94HB648GJk8HAmmj5d zroDtb6CTTx+xxaTCQ2INRyrtaPCDwz3lgtlwKQ0kMy0osNr0H/uCLxNKLS4soVIbEdV bZoCR77WYxI9E+dK7noWKgRlRtWHtMhS8tDWnZPzv9HHCvyfjLHEXd5IBhvNVx9pc+kA riUaH0TrtVfUv9v82r1iAjErGpxKFCqvzeeqJvSYe48Q84AVupQUdckODKdQQ1rwBqvo svUodleII3QRFUGNrVfXang9L9rkgKlJmfo0R8tTspch1Wzt877Sh1F50TeoQf/fz+ts VCpA== X-Gm-Message-State: AOAM533iBXTPmTE4OMhwi+1KkA7X8ItDs//UF5iAqal9HuOFSOH7/+Dr vI1F78mq8jkbFXch2S8ItfVIBr8m3PxBXOLCh4s= X-Google-Smtp-Source: ABdhPJzYOr71U9WbVzTamYvT/82rJZbBFVowVmunIbLznCy4P3ecSnDvgUITP2H1sojiVPW1Ima7dTSXMDLnosQKXkQ= X-Received: by 2002:a02:c98d:: with SMTP id b13mr28217971jap.124.1607885039730; Sun, 13 Dec 2020 10:43:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sun, 13 Dec 2020 19:43:48 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="000000000000a2044405b65ce8f1" Archived-At: Subject: Re: [GNAP] physical person 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, 13 Dec 2020 18:44:02 -0000 --000000000000a2044405b65ce8f1 Content-Type: text/plain; charset="UTF-8" Hi, Wasn't thinking about that, but yes. Natural person would be good. I change it in the wiki. Thxs Fabien On Sun, Dec 13, 2020 at 7:07 PM Tom Jones wrote: > I dislike this. A robot can be a physical person. What's wrong with > natural person that others use? > Peace ..tom > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a2044405b65ce8f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    Wasn't thinking=C2=A0abou= t that, but yes.
    Natural person would be good. I change it in the= wiki.=C2=A0

    Thxs
    Fabien

    =
    On Sun, De= c 13, 2020 at 7:07 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    I dislike this. A robot can be a physical person. Wh= at's wrong with natural person that others use?
    Peace ..tom
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000a2044405b65ce8f1-- From nobody Sun Dec 13 10:46:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE983A0982 for ; Sun, 13 Dec 2020 10:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=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 Li8Fdcon5cMS for ; Sun, 13 Dec 2020 10:46:05 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33ED3A0983 for ; Sun, 13 Dec 2020 10:46:05 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id q1so13820258ilt.6 for ; Sun, 13 Dec 2020 10:46:05 -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=XKjWbXSjLqUr/OlfDCUIhPNrJ5OcENdHNwpVDd+U9W4=; b=KOT8F8Ko23qfQMyDsfoBCDWLTEqZTZ+H7oLUJ6i8WH4svLxujjepP9KLpLsig3PhZL 3OUORSbnnPU5k9tVxE2G06Dj+aN1uZTxyX7t2UDeR3eOEBTPgx922046OWqoivk23PwH RQQXsJaZ/pcDEYy/oBztfbAmXd6+VKW0njKHaqesrdYSl38YF2kGY9d9IErK1pShCZSq T90RZ/HqDPZA10nbHFVkFp80UGMS+f57VQlT+6h2ylSsYNAh4D9LgdyZnOXZAXPN967E 43qtrwvZWn+CWmOZnK3GVCMlYP62and8Ws1GgG86xmw3JWfyLzVstvBgsAjkFnZDfy+6 xxrA== 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=XKjWbXSjLqUr/OlfDCUIhPNrJ5OcENdHNwpVDd+U9W4=; b=GAd4o92k5QCgCsGIDTAvRiPeUlCnCs7XampBxsrRSwyX7oQRMYl2yC7YnPcUdFmRSl /Ftzba/iFHAJ/k6SGyKoqx6JxcqaUkICSFE1Ws7/dkFWKKPyVFEdbskTVwf6ciS2Jp2M 2ctizWR3jyKfHOZLF07sFwToxFFOkEw88vl9bzZI1naYgi8gESPjW5jIyYc/pzbOTcJv qyA05wN5bBV0p07Gs8hq7fXj9GSP9VhyLCnZhIA3Ab+NEsl9rmBp2Ct0TZwWhEpJ0L2D dEbErWpeq1tStFicPG6Cz8W+UGwwwgd3Rlvy5yhTgUgTgF2th708wGxMkNjC/iIgpdm0 r3bQ== X-Gm-Message-State: AOAM533sAMFYcs2HsUFoycE1azfOb01ayLu51sUHVyajK7bHvYHPSoLg 26ipxy3JD2TcT9CYS+NhFB40qshkAdz+vdxxd48= X-Google-Smtp-Source: ABdhPJwCwFv8IvIyPdIRBDvhjQEL/SFmnNgQGRcZ/nDQyHOSijP/oLh3MlNskcNzxy/1zdrnAM3vfzUruxJ2I+oA2eA= X-Received: by 2002:a92:ce44:: with SMTP id a4mr30592502ilr.178.1607885165017; Sun, 13 Dec 2020 10:46:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sun, 13 Dec 2020 19:45:54 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="00000000000019bee705b65cf0d5" Archived-At: Subject: Re: [GNAP] grant - noun 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, 13 Dec 2020 18:46:07 -0000 --00000000000019bee705b65cf0d5 Content-Type: text/plain; charset="UTF-8" well, for the verb, I just took the definition from https://www.merriam-webster.com/dictionary/grant The noun has been customized. On Sun, Dec 13, 2020 at 7:09 PM Tom Jones wrote: > this is not an act but an artifact of an act > > Peace ..tom > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000019bee705b65cf0d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    well, for the verb, I just took the definition from=C2=A0<= a href=3D"https://www.merriam-webster.com/dictionary/grant">https://www.mer= riam-webster.com/dictionary/grant
    The noun has been customized.=C2= =A0

    On Sun, Dec 13, 2020 at 7:09 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
    =
    this is not an act but an artifact = of an act

    Peace ..tom
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --00000000000019bee705b65cf0d5-- From nobody Sun Dec 13 10:48:58 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989A03A098A for ; Sun, 13 Dec 2020 10:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtRD05RdckbH for ; Sun, 13 Dec 2020 10:48:55 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF363A0989 for ; Sun, 13 Dec 2020 10:48:55 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id v3so13821942ilo.5 for ; Sun, 13 Dec 2020 10:48:55 -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=UZX3prClN6yBTrkUS/JDBjVS/YVPr2eALpnHW1yDmV4=; b=kgD+7pDByk87CEQDmHKmD1dMxw9brlP8vIOBUZwwG2q/a9299NHw/Imfg6BOaLPBrd 1rEH8e4Q3jPeKqthRHzp21QgI1+/U5GTJP1EQ6T21JdOYf9JVje2JnDc52naYZw1hbNm GO7RpZ90qfFrz8OrpEqp8fzlgIyBb6O6BA/cc3+PpqveAbKP45THpfrkdJhXDa5UfXxG c5oiALrD+L2bsl81gLFubky6AhWIJfJYSmBcZopFlN7R82HqYLqve/4J9qJVDvnVHlJz UsnDnhQoG91XuQNw2zDOw/Dm2qr6vfl2HDBjGoaNHZJfJcylFx83hvgdqhmRJ2aDXGrw x/QQ== 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=UZX3prClN6yBTrkUS/JDBjVS/YVPr2eALpnHW1yDmV4=; b=RfOCOsq0/pHjt3snrbmwhEu8ee42c2XxxOWiEksh2Neb5wB5DNvxLlA159NaWJj4es 7HTkQ9wn46PKJ/tlcK9a/WtZG6a4N/HGPj5NwzJAisA0U/BJlEpfSrehUk8w2ynF3vbG KfzZNC3PXB+E78CM5xV3EDGclLsbAR4TwWvLJgP3b1u3hK6iTFH3ChjikiaaFWurC0hu MTUbzSFJrxuIMFv420DEaZq88+lLXr03kBKBZm3GRZyM/NXJYPGGmJe+nCDwuj/17Dzz vEXElC2zTv+CPm/UiRh88fvXDmX1rxrnzVO2pvMaQMiBtY2TdxiEzK7Bg03FQ0nOUpsx fy3g== X-Gm-Message-State: AOAM532XT+7PMR5vkwxrsJ/2pXfJU7zpwcGL8qKxa+HdvfKNr3hz/Alh RZhx+Xcb4J5ZW97uEjV0s7FKPKy0VKeUCjPtj88= X-Google-Smtp-Source: ABdhPJzmm7p27Fbaarj1D7UIa5M3+r7rmTYvp+X5x1X9Icir4WwfD27+ZuUto60Wgai0RG2xziOT3+jA+n828qC0HC0= X-Received: by 2002:a92:ce44:: with SMTP id a4mr30606462ilr.178.1607885334670; Sun, 13 Dec 2020 10:48:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Sun, 13 Dec 2020 19:48:43 +0100 Message-ID: To: Tom Jones Cc: txauth gnap Content-Type: multipart/alternative; boundary="00000000000036737105b65cfa45" Archived-At: Subject: Re: [GNAP] notes about what the standard does (eg key) 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, 13 Dec 2020 18:48:57 -0000 --00000000000036737105b65cfa45 Content-Type: text/plain; charset="UTF-8" Hi Tom, That's the second feedback (with Denis) saying "key" shouldn't be in the terminology. So I'll put the term in a pending delete state (which means it wouldn't be included in the PR), unless a majority thinks otherwise. We would take your advice and put that in a more appropriate section. Changing the wiki to reflect that. Fabien On Sun, Dec 13, 2020 at 7:11 PM Tom Jones wrote: > do not belong in the terminology but in a normative section or the > introduction. > > Peace ..tom > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000036737105b65cfa45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Tom,=C2=A0

    That's the second fee= dback (with Denis) saying "key" shouldn't be in the terminolo= gy. So I'll put the term in a pending delete state (which means it woul= dn't be included in the PR), unless a majority thinks otherwise.=C2=A0<= /div>

    We would take your advice and put that in a more a= ppropriate section.=C2=A0

    Changing the wiki to ref= lect that.

    Fabien

    On Sun, Dec 13, 2020 at 7:1= 1 PM Tom Jones <thomascl= inganjones@gmail.com> wrote:
    do not belong in the terminology but i= n a normative section or the introduction.

    Peace ..tom
    =
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --00000000000036737105b65cfa45-- From nobody Sun Dec 13 11:12:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564B23A09E0 for ; Sun, 13 Dec 2020 11:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 yttcEbYJdpoK for ; Sun, 13 Dec 2020 11:12:23 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 F19643A09DF for ; Sun, 13 Dec 2020 11:12:22 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id y17so14260142wrr.10 for ; Sun, 13 Dec 2020 11:12:22 -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=HXE+al3YD5Rl+5MyKfRxsop1jmWgzZ7vay/eyNthCXI=; b=IJaBec+v5cnNBr7pWQdOb5O/DeuEEBjTYmnvpdHJxURLZo0NrmLqY0/KAOx45kPVK1 dzmmTYp2QUwyoe9dgiQLL1cHJPoFjnjZaA39jR6VF/an1dbtLOjE9aD85NXz7LhNk7WI di3JZhHkTnx27BaoHJ/DCB+QQua9hoCqWlX+OrSHzMMCB6pts3+wxc6MzwPsqoJfoXzw E8eMIZSpb6TDoyyd26KjGw1EWXrZ7L/qomoC2+DwaSXNGEHj85lTDK4zP9j0lGtL3OUe Wpsokdop6Vkoe+UYOyYbNIZW0xHDZ8hHnss0ennXkPh5do0e5xOVhpCyaSdlypwvrxQE oq6Q== 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=HXE+al3YD5Rl+5MyKfRxsop1jmWgzZ7vay/eyNthCXI=; b=kHOyXv1lK2v9NKoyxFmTfTGbb6afzQduYen4SpsZdSJYc8LWycFsEbNYs2XF7oatEs tBo8Byn8RPGvob4tR8zdltj2lTiKvJ1qS7nnTAcp1xl+HK/Of86JKip9pQQFm6GMP/wO Fj3RTXLK35bSJnEO+TvsvCd+/y4lnR0BG+YdWUNx7v23X/O6Bvf3qZuOEK6E7cYzGdto eDiLE5Fm9NWYPJtAKXvsusMER9A5Z0nc7iRPcBIn60vZtmrQViKi8yYCgGJTNw90lr7c 7pJkL6yfHeEVROA8jlFwZbNk1rW/zYURf8v7kkyp2FPzZXy5F5W4TuZafYsGg0h6uC1v 5nSw== X-Gm-Message-State: AOAM530HqFF8Yx6ArEzlvyakgbnk1EMt6iyri+aFKQfGHZQ70zZJWZId M06p9e4V77EB1phhjlwMbWg= X-Google-Smtp-Source: ABdhPJwW4UUO4Y4vIcOD0q0G206ew9AIVdZtGTT0WNLtvci+3qnHtvuYtNT3pi51Mwv/0jQp2zO1Rg== X-Received: by 2002:adf:83c7:: with SMTP id 65mr25360027wre.221.1607886741137; Sun, 13 Dec 2020 11:12:21 -0800 (PST) Received: from [192.168.68.107] (bzq-79-178-108-177.red.bezeqint.net. [79.178.108.177]) by smtp.gmail.com with ESMTPSA id a144sm27092586wmd.47.2020.12.13.11.12.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Dec 2020 11:12:20 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.43.20110804 Date: Sun, 13 Dec 2020 21:12:18 +0200 From: Yaron Sheffer To: Fabien Imbault CC: Denis , GNAP Mailing List Message-ID: <13422918-A279-45FD-97B7-E02D74534960@gmail.com> Thread-Topic: [GNAP] Terminology proposal References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3690738739_988194379" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 19:12:28 -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_3690738739_988194379 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9Cserver that de= nies operations=E2=80=9D) a bit funny. How about: =20 Resource Server (RS) Definition: server that provides operations on protected resources; such op= erations typically require that the client provide valid access tokens issue= d by an AS Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Fabien Imbault Date: Sunday, December 13, 2020 at 13:20 To: Yaron Sheffer Cc: Denis , GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hello everyone,=20 =20 We're at the end of the 2 week period, and so I integrated the various feed= backs :=20 =20 a) from Yaron's feedback, removed new term "IS" and update issue https://gi= thub.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle the proposal h= ere=20 b) integrated Tom's feedback regarding the RO (and moved to access token) c) definitions follow an ISO style as suggested by Denis, which we took as = a starting point (but I made the modifications I felt were necessary) =20 I modified the definitions, notes and examples as a consequence. You'll als= o find a summary of discussions for each term, so that we can keep track of = them too. =20 My biggest question is : what should we use as our main vocabulary between = privilege/rights/attribute? I tried to clarify, please let me know what you = think. The general idea is that we grant privileges that are delivered under= the form of access tokens (which contain rights and/or attributes). Regarding whether access tokens should be opaque or not, I suggest to remov= e that from the definition and handle that in issue https://github.com/ietf-= wg-gnap/gnap-core-protocol/issues/145 =20 All has been consolidated on the wiki too https://github.com/ietf-wg-gnap/g= nap-core-protocol/wiki/Terminology so that we have a clearer view of where w= e stand.=20 =20 Please comment further on the list if you have comments, I'll update if nec= essary (and refer to the mailing list url in the comment of the wiki update,= from now on). Then editors will review the proposal.=20 Here is a copy of https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/T= erminology#latest-discussion-update. =20 Latest discussion update Here we consolidate the latest proposal(s) from the group. We also include = the discussion items (individual feedbacks). Authorization Server (AS) Definition: server that grants privileges to a particular end-user and that= provides them to a client in the form of an access token Feedbacks / discussion / questions : Suggested "privilege" definition (that we would probably add as an addition= al sub-entry): "A privilege is the right to perform an operation (or action)= on a Resource." See also other def Note that we don't include claims in the definition (cf OIDC/SSI integratio= n), but since we talk about a "particular end-user" it is assumed somehow Denis suggested we used "rights and attributes" instead of privileges. [FI]= However i don't think one can really speak about granting attributes, excep= t indirectly (ABAC). See access token for more on that, where we can be more= specific. Do we allow cases such as distributing the AS on a mobile? (in this case we= 're at the limit of what we call a server) Client Definition: application used by an end-user to interact with an AS or a RS Note: this specification differentiates between a specific instance (the cl= ient instance, identified by its public key) and the software running the in= stance (the client software). For some kinds of client software, there could= be many instances of a single piece of client software. Example: a client can be a mobile application, a web application, etc. Feedbacks / discussion : Replaces previously proposed RC, we wouldn't provide a short name. Keep OAuth2 term, but we clarify it Further discussion on Client instance Resource Server (RS) Definition: server that denies operations on protected resources, unless th= e client provides valid access tokens issued by an AS Feedbacks / discussion : Denis suggests to make explicit that we could have several ASs - "issued by= one or more ASs" (also we'd need a convention on how to denote plural, e.g.= ASs). Not exactly sure right now of the multiple issuance would work, so ne= eds to be clarified. Also not sure if that's even necessary (do we lack in g= enerality if we keep the singular?) Resource Owner (RO) Definition: physical person acting on its own or representing an organizati= on, that may grant privileges on resources he has authority upon Note: the act of granting privileges may be manual (i.e. through an interac= tion) or automatic (i.e. through predefined rules). Feedbacks / discussion As some point we suggested "The RO may decide to remove its consent at any = time." Tom provided useful feedback on that. Moved to access token where it = fits more naturally. End-user Definition: physical person that operates with the client software Note: that physical person may or may not be the same entity as the RO Access token Definition: digitally signed data that contains specific rights and/or attr= ibutes Note 1: the access token can be issued to an end-user (usually requiring hi= s authentication) and subsequently refreshed. The AS usually provides a meth= od for the RO to revoke the privileges at any point in time. Note 2: an access token may act as a capability (i.e. bearer token) or requ= ire an additional authentication by binding to a key (i.e. bound token) Feedbacks / discussion Would require the subdefinitions right: ability for an end-user to perform = a given operation (or action) on a resource (or object) under the control of= a RS / attribute: property related to an end-user. Note 2 is here in relationship with PR 129 Grant Definition (verb): to permit, as a privilege given to an end-user to exerci= se some rights and/or assert attributes during a specific duration Definition (noun): the act of granting Key Definition: public cryptographic binding a request to the holder of a priva= te key, used by the protocol entities (AS, RS, client instance, bound token,= etc.) to identify themselves. Note: a key can be rotated or revoked by its holder. The protocol supports = the update of the key information. Feedbacks / discussion Denis thinks the term "key" is well understood and doesn't need to be defin= ed. Yet, I tend to believe we'd gain to keep it. First the generic term "key= " may be many things : symmetric/asymmetric, public/private, etc. It's also = useful to explain its use in the protocol Resource Definition: protected API served by a RS and accessed by a client, if and o= nly if a valid access token is provided =20 On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault w= rote: Hi Yaron,=20 =20 Yes I highlighted that this was a new term. We can deal with it as a separa= te issue indeed.=20 =20 Best Fabien =20 On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer wrote= : Hi Fabien, =20 Yes, we definitely need to reach closure on terminology, thank you for driv= ing this discussion! =20 One process comment: unless I=E2=80=99m missing something, the Interact (or Inter= action) Server is not mentioned in the current draft. I suggest we do not in= troduce new functional components or new behaviors as part of the terminolog= y discussion. Specifically, if the IS is useful, let=E2=80=99s reach consensus on = that separately. Then we can add it into the Terminology section. =20 Thanks, Yaron =20 From: TXAuth on behalf of Fabien Imbault Date: Friday, December 11, 2020 at 14:31 To: Denis Cc: GNAP Mailing List Subject: Re: [GNAP] Terminology proposal =20 Hi Denis,=20 =20 Thanks for your detailed feedback. My comments are embedded into your messa= ge. Again those comments are my own, and we'll need to converge to some cons= ensus beyond what I say here. My main open question is really about the RO b= eing optional. Could you explain? =20 Fabien=20 =20 On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: This is a global response to the definitions proposal.=20 =20 Terminology I propose to adopt the way ISO defines how to write the definitions. It is a single sentence that may be substituted to the wording being define= d in the context of a sentence that uses that definition.=20 Since this single sentence can be substituted to the wording, there is not = point at the end of that sentence. The sentence does not=20 have a "a" or "the" in front of it. =20 [FI] In the first version, I was mostly trying to not get too far away from= the current text. But yes that's a good idea, it gives a more formal rule, = which has been proven to work.=20 =20 If more information is useful to understand the wording, it is placed in on= e or more notes afterwards. =20 Note: The ISO rules for drafting definitions are in the ISO/IEC Directives,= Part 2 (edition 2018): 16.5.6 Definitions The definition shall be written in such a form that it can replace the term= in its context. It shall not start with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor= end with a full stop.=20 A definition shall not take the form of, or contain, a requirement. Only one definition per terminological entry is allowed. If a term is used = to define more than one concept, a separate terminological entry shall be cr= eated=20 for each concept and the domain shall be included in angle brackets before = the definition. Circular definitions, which repeat the term being defined, are not allowed. Comments are inserted between the lines. =20 Hello everyone, =20 =20 As an editor : a quick reminder that terminology issues will be discussed i= n the coming weeks, and we're expecting your inputs right now (according to = the process previously sent on the mailing list). https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology=20 =20 The rest of this message is a proposal written in my own name, and doesn't = involve discussions with the editors/chairs who might have different opinion= s. =20 Authorization Server (AS) Manages the granting of privileges to a third-party client instance. If the= RO consents to at least a part of what is requested, the AS issues an acces= s token to the client.=20 My questions:=20 - was else do we issue? (e.g. id claims, payment info, etc.) We could have = more than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not clear. I remo= ved that for now. - there might potentially be several AS, currently we don=E2=80=99t reflect that = anywhere. If would leave that as an open item, depending on what we end up d= oing in the spec I am not in favour of this definition: A RO as defined later: "authorizes t= he request to access a protected resource from the RS to the client".=20 This does not mean in any way that a RO has necessarily a direct relationsh= ip with one or more ASs. [FI] indeed we could remove that limitation, to hav= e a more general definition Using the ISO style for definitions, I propose: Authorization Server (AS): server that grants rights and/or attributes to a= particular end-user and that provides them to a client in the form of an ac= cess token Since this definition is using the words "rights" and "attributes", these t= wo terms need to be defined as well. right: ability for an end-user to perform a given operation on an object un= der the control of a RS attribute: property related to an end-user =20 [FI] I like your proposal in general. There might be some discussions on th= e details. I don't think it makes sense to grant "attributes". =20 Some explanations: a "right" is able to support a capability scheme. An "at= tribute" is able to support an ACL scheme.=20 These two schemes are able to support "discretionary access control" where = the end-user has a "need-to-know".=20 However, some attributes are also able to support what was called in the p= ast "mandatory access control"; for example,=20 if the end-user is cleared to "top-secret / marketing strategy". =20 Interact Server (IS) - this is a new proposed term Manages the front-end interaction with the RO, in order to gather its conse= nt. Depending on the deployment model and the privacy requirements,=20 the IS may be a component of the AS, or may be distinct and managed by anot= her party. Example : an IS usually involves a web interface accessed by RO through a w= eb browser.=20 Note : an IS is not always required, especially if the access is granted th= rough automated policies. Using the ISO style for definitions, I propose: =20 Interaction Server (IS)=20 component from the AS or server interfacing with an AS that manages the int= eractions with a RO, in order to gather its authorization Note : since the RO is an optional component, the IS is also an optional co= mponent. =20 [FI] indeed IS is optional. note for myself when looking at RO : why is RO = optional ? =20 Client=20 Requests privileges from the AS, and uses access tokens at the RS. This spe= cification differentiates between a specific instance (the client instance, = identified by its unique public key)=20 and the software running the instance (the client software). . For some kin= ds of client software, there could be many instances of a single piece of cl= ient software. The AS determines which policies apply to a given client instance, includin= g what it can request and on whose behalf. Some comments: The above text is stating: "(the client instance, identified= by its unique public key)".=20 A client instance may use a public key, but that key is not necessarily uni= que, in particular when there are multiple ASs. [FI] yes, although when possible I would still consider a better practice t= o expose a key to a specific AS and not to the entire set of available ASs.=20 Example : a client can be a mobile application or a web application (the cl= ient software) that requires authorizations from the RO to retrieve content = from various protected APIs. The client instance may for instance refer to a= specific version of that client software. See on-going discussion : https://github.com/ietf-wg-gnap/gnap-core-protoco= l/pull/132 (client instance).=20 Using the ISO style for definitions, I propose: Client: application used by an end-user to interact with an AS or a RS Note: a client can be a mobile application or a web application [FI] for me= those are just examples, because there could me more (ex IoT device) [FI] you remove the entire discussion on client instance / client software,= is that on purpose because you think it's not useful/right, or is it becaus= e of something else? (maybe add your comment of the related issue) =20 Resource Server (RS) Accepts valid access tokens from the client issued by the AS and serves pro= tected resources on behalf of the RO. There could be multiple RSs protected = by the AS that the client may call. Example : a RS is often composed of protected APIs that can be consumed by = authorized client software. =20 One comment: a RO is not necessarily involved. [FI] a bit hard to imagine, = there's some kind of owner. Could you be more explicit? Using the ISO style for definitions, I propose: Resource Server (RS): server that accepts valid access tokens from clients = issued by one or more ASs which are used to grant or deny some requested ope= rations Note: a RS is often composed of protected APIs that can be consumed by clie= nts. =20 Resource Owner (RO) Authorizes the request to access a protected resource from the RS to the cl= ient. The RO may decide to remove its consent at any time. Note : the RO may be a physical person or may represent an organization. =20 Two comments: In order to avoid confusion with the end-user consent, the wo= rd " authorization" is being used instead of "consent". [FI] ok=20 It should be said that the RO is an optional component. [FI] why? Using the= ISO style for definitions, I propose: Resource Owner (RO): physical person acting on its own or representing an o= rganization that authorizes to clients operations on protected resources fro= m a RS Note: The RO is an optional component that may interact either with one RS = or with one or more ASs ,e.g. using an IS. End-user =E2=80=93 this was previously Requesting Party RQ A physical person that operates and interacts with the client software.=20 Note : the end-user may or may not be the same entity as the RO.=20 The Note is slightly incorrect. the physical person may or may not be the s= ame entity as the RO. [FI] I didn't understand your comment Using the ISO style for definitions, I propose: End-user : physical person that operates and interacts with the client sof= tware=20 Note : that physical person may or may not be the same entity as the RO.=20 =20 Access Token A set of privileges delegated to the client instance for a specific end-use= r. An access token is created by the AS, consumed and verified by the RS, an= d issued to and carried by the client's end-user on behalf of the RO. The co= ntents and format of the access token are opaque to the client. Example : JWT is a commonly used format.=20 Note 1 : an access token generally has a limited duration, after which it m= ay be refreshed at a regular interval. Note 2 : an access token may be revoked at any time by the RO.=20 Note 3 : an access token may act as a capability or require an additional a= uthentication by binding to a key=20 A fundamental point: the third sentence from the definition states: "The co= ntents and format of the access token are opaque to the client". [FI] I'll check your other thread dedicated to that issue=20 See my other email sent today about "RS-Token Introspection or RC-Token Int= rospection" where I conclude: For end-users caring about their privacy (or for systems willing to p= rotect the user's privacy), access tokens should not be considered to be opaque to RCs nor to RSs and ASs should not support Token Intro= spection, whether it is RS-Token Introspection or RC-Token Introspection. The example and the other Notes above should be removed. If needed they sho= uld be placed in the main body of the document. Using the ISO style for definitions, I propose:=20 Access Token : digitally signed data issued by an Authorization Server (AS)= and consumed by a Resource Server (RS)=20 that contains rights and/or attributes granted to = a particular end-user =20 Grant The process by which the client requests and is given delegated access to t= he RS by the AS through the authority of the RO. Using the ISO style for definitions, I propose: Grant: permission given to end-user to use a subset of his rights and/or hi= s attributes at a specific time and for a specific duration =20 Key A public cryptographic binding a request to the holder of a private key. Ac= cess tokens and client instances can be associated with specific keys at a p= oint in time.=20 Note : a key can be rotated or revoked by its holder. The protocol supports= the update of the key information.=20 "key" is a general term that is well understood and that does not need to b= e defined. [FI] I really wouldn't bet on that. We can reuse an existing defi= nition but it is a central piece so we need to be explicit The "definitions" section is not intended to explain what can be done with = the term that is being defined. [FI] ok we can work on that Until the word "key" is qualified using one or more other terms, this defin= ition should be removed. =20 Resource A protected API served by the RS and accessed by the client if and only if = access has been granted. Access to this resource is delegated by the RO as p= art of the grant process. The second sentence of the definition is not in accordance with the ISO sty= le or definitions and furthermore this second sentence should be removed sin= ce a RO is an optional element. =20 Using the ISO style for definitions, I propose:=20 Resource: protected API served by a RS and accessed by a client, if and onl= y if access is granted by an access token=20 Subject Information Information about a subject (usually a RO) that is returned directly to the= client from the AS. Note : this information needs to be unique.=20 =20 This definition exhibits several problems:=20 (1) The term "subject" is not defined.=20 (2) The information that is returned is for an end-user, i.e. not for "(usu= ally a RO)".=20 (3) The Note states : "this information needs to be unique". Does it mean u= nique for the AS ? globally unique ?=20 This definition should be revisited. [FI] I agree (I myself had many questi= ons here) Denis =20 My questions :=20 - probably we=E2=80=99d need to define subject Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697= /Subject+Dictionary+Entry - might be useful to clarify the relationship to what identity providers do= =20 =20 =20 Cheers Fabien =20 =20 =20 =20 =20 --=20 TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3690738739_988194379 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

    It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80=9Cserver that d= enies operations=E2=80=9D) a bit funny. How about:

     

    Resource Server (RS)

      Definition: server that = provides operations on protected resources; such operations typically requir= e that the client provide valid access tokens issued by an AS

    Thanks,

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

    &nbs= p;

    From: Fabien Im= bault <fabien.imbault@gmail.com>
    Date: Sunday, December 13, = 2020 at 13:20
    To: Yaron Sheffer <yaronf.ietf@gmail.com>
    <= b>Cc:     Denis <denis.ietf@free.fr>, GNAP Mailing List <txauth@iet= f.org>
    Subject: Re: [GNAP] Terminology proposal

     

    Hello everyone, 

    =  

    We're at the end of the 2 week= period, and so I integrated the various feedbacks : 

     

    a) from Yaron's feedback, removed new term "IS" and update issue=  https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handl= e the proposal here 

    b) int= egrated Tom's feedback regarding the RO (and moved  to access token)

    c) definitions follow an ISO style= as suggested by Denis, which we took as a starting point (but I made the&nb= sp;modifications I felt were necessary)

     

    I modified the de= finitions, notes and examples as a consequence. You'll also find a summary o= f discussions for each term, so that we can keep track of them too.

     

    My biggest question is : what should we use as our main vocabular= y between privilege/rights/attribute? I tried to clarify, please let me know= what you think. The general idea is that we grant privileges that are deliv= ered under the form of access tokens (which contain rights and/or attributes= ).

    Regarding whether access toke= ns should be opaque or not, I suggest to remove that from the definition and= handle that in issue https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/145

     

    All has been consolidated on the wiki too&nb= sp;https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology= so that we have a clearer view of where we stand. 

     

    = Please comment further on the list if you have comments, I'll update if= necessary (and refer to the mailing list url in the comment of the wiki upd= ate, from now on). Then editors will review the proposal. 

     

    Latest discussion update<= o:p>

    Here we consolida= te the latest proposal(s) from the group. We also include the discussion ite= ms (individual feedbacks).

    Autho= rization Server (AS)

    • Definition: server that grants privileges t= o a particular end-user and that provides them to a client in the form of an= access token

    Feedbacks / discussion / questions :

    • Suggested "privil= ege" definition (that we would probably add as an additional sub-entry)= : "A privilege is the right to perform an operation (or action) on a Re= source." See also other def
    • Note that we don= 't include claims in the definition (cf OIDC/SSI integration), but since we = talk about a "particular end-user" it is assumed somehow
    • Denis suggested we= used "rights and attributes" instead of privileges. [FI] However = i don't think one can really speak about granting attributes, except indirec= tly (ABAC). See access token for more on that, where we can be more specific= .
    • Do we a= llow cases such as distributing the AS on a mobile? (in this case we're at t= he limit of what we call a server)

    Client

    • Definition: application used by an end-user to i= nteract with an AS or a RS
    • Note: this specification differentiates between a specific= instance (the client instance, identified by its public key) and the softwa= re running the instance (the client software). For some kinds of client soft= ware, there could be many instances of a single piece of client software.
    • = Example: a = client can be a mobile application, a web application, etc.

    Feedbacks / discussion :<= o:p>

    • Replaces previously proposed RC, we wouldn't provide a short nam= e.
    • Keep O= Auth2 term, but we clarify it
    • Further discussion on Client instance

    Resource Server (RS)
    • Defini= tion: server that denies operations on protected resources, unless the clien= t provides valid access tokens issued by an AS
    Feedbacks / discussion :

    • D= enis suggests to make explicit that we could have several ASs - "issued= by one or more ASs" (also we'd need a convention on how to denote plur= al, e.g. ASs). Not exactly sure right now of the multiple issuance would wor= k, so needs to be clarified. Also not sure if that's even necessary (do we l= ack in generality if we keep the singular?)

    Resource Owner (RO)

      Definition: physical perso= n acting on its own or representing an organization, that may grant privileg= es on resources he has authority upon
    • Note: the act of granting privileges may be man= ual (i.e. through an interaction) or automatic (i.e. through predefined rule= s).

    Feedb= acks / discussion

    • As some point we suggested "The RO may de= cide to remove its consent at any time." Tom provided usef= ul feedback on that. Moved to access token where it fits more natur= ally.

    End-user<= /span>

    • Note: that phys= ical person may or may not be the same entity as the RO

    Access token

    • Definition: digitall= y signed data that contains specific rights and/or attributes
    • Note 1: the access tok= en can be issued to an end-user (usually requiring his authentication) and s= ubsequently refreshed. The AS usually provides a method for the RO to revoke= the privileges at any point in time.
    • Note 2: an access token may act as a capabilit= y (i.e. bearer token) or require an additional authentication by binding to = a key (i.e. bound token)

    Feedbacks / discussion

      <= li class=3DMsoNormal style=3D'color:#24292E;mso-margin-top-alt:auto;mso-margin-b= ottom-alt:auto;mso-list:l11 level1 lfo11;box-sizing:border-box'>Would require the subde= finitions right: ability for an end-user to perform a given operation (or ac= tion) on a resource (or object) under the control of a RS / attribute: prope= rty related to an end-user.
    • Note 2 is here in relationship with PR 129

    Grant

    • Definition (ver= b): to permit, as a privilege given to an end-user to exercise some rights a= nd/or assert attributes during a specific duration
      • Definition (noun): the act of gr= anting

    Key

    • D= efinition: public cryptographic binding a request to the holder of a private= key, used by the protocol entities (AS, RS, client instance, bound token, e= tc.) to identify themselves.
    • Note: a key can be rotated or revoked by its holder. T= he protocol supports the update of the key information.

    Feedbacks / discussion

    • Denis thinks the term "key" is well understood and doesn't = need to be defined. Yet, I tend to believe we'd gain to keep it. First the g= eneric term "key" may be many things : symmetric/asymmetric, publi= c/private, etc. It's also useful to explain its use in the protocol

    Resource

  • = Definition:= protected API served by a RS and accessed by a client, if and only if a val= id access token is provided

    •  

    On Fri, Dec 11, = 2020 at 6:05 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:

    Hi Yaron, 

     

    Yes I highlighted that this was a new term. We can deal with it a= s a separate issue indeed. 

     

    Best

    Fabien

     

    On Fri, Dec 11, 2020 at 6= :02 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,

    &nb= sp;

    Yes, we definitely need to reach closure on terminology,= thank you for driving this discussion!

     

    One process comment: unless I=E2=80=99m missing something, the Interact (or Int= eraction) Server is not mentioned in the current draft. I suggest we do not = introduce new functional components or new behaviors as part of the terminol= ogy discussion. Specifically, if the IS is useful, let=E2=80=99s reach consensus o= n that separately. Then we can add it into the Terminology section.

     

    Thanks,

       &nb= sp;            Yaron<= o:p>

     

    From: T= XAuth <txauth-bo= unces@ietf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com>
    = Date: Friday, December 11, 2020 at 14:31
    To: Denis <denis.ietf@free.fr>
    <= b>Cc: GNAP Mailing List <txauth@ietf.org>
    Subject: Re: [GNAP] Terminology propo= sal

     

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

     

    Than= ks for your detailed feedback. My comments are embedded into your message. A= gain those comments are my own, and we'll need to converge to some consensus= beyond what I say here. My main open question is really about the RO being = optional. Could you explain?

     

    Fabien 

     

    =

    On Fri, Dec 11, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:<= /p>

    This is a global response to the definitions = proposal.

     

    Terminology

    I propose to adopt the way ISO defines how to= write the definitions.

    = It is a single sentence that may be substituted to the wording being defined in the context o= f a sentence that uses that definition.
    Since this single sentence can b= e substituted to the wording, there is not point at the end of that sentence= . The sentence does not
    have a "a" or "the" in front= of it.

     

    [FI] In the first version, = I was mostly trying to not get too far away from the current text.&nb= sp;But yes that'= s a good idea, it gives a more formal rule, which has been proven to work.&n= bsp;

     

    If more information is useful to understand th= e wording, it is placed in one or more notes afterwards.

     

    Note: The ISO rules for drafting d= efinitions are in the ISO/IEC Directives, Part 2 (edition 2018):<= /p>

    16.= 5.6    Definitions

    The definition shall be written = in such a form that it can replace the term in its context. It shall not sta= rt with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end with a full stop.
    A defi= nition shall not take the form of, or contain, a requirement.

    Only on= e definition per terminological entry is allowed. If a term is used to defin= e more than one concept, a separate terminological entry shall be created for each concept and the domain shall be included in angle brackets before= the definition.

    Circular definitions, which repeat the term being de= fined, are not allowed.

    Comments are inserted between the lines.

     

    Hello everyone, 

     

    As an editor : a quick remi= nder that terminology issues will be discussed in the coming weeks, and= we're expecting your inputs right now (according to the process previously = sent on the mailing list).

    https://github.com/ietf-wg-gnap/gnap-core-protocol/wi= ki/Terminology 

     

    The rest of this message is a proposal written in my own name, and= doesn't involve discussions with the editors/chairs who might have differen= t opinions. 

    Authorization Server (AS)

    Manages the granting of privileges = to a third-party client instance. If the RO consents to at least a part of w= hat is requested, the AS issues an access token to the client. <= /o:p>

    My questions: <= /o:p>

    - was else do we issue? (e.g. i= d claims, payment info, etc.) We could have more than access tokens, but =E2=80=9C= directed information=E2=80=9D is not clear. I removed that for now.

    - there might potentially be = several AS, currently we don=E2=80=99t reflect that anywhere. If would leave that = as an open item, depending on what we end up doing in the spec

    I am not in favour of this = definition: A RO as defined later: "authorizes the request to access a = protected resource from the RS to the client".
    This does not mean i= n any way that a RO has necessarily a direct relationship with one or more A= Ss.     [FI] indee= d we could remove that limitation, to have a more general definition<= o:p>

    Using the ISO style for def= initions, I propose:

    Authorization Server (AS): server that g= rants rights and/or attributes to a particular end-user and that provides th= em to a client in the form of an access token

    Since this definition is using the words "rights" and "attributes", these two terms need to be defined= as well.

    right: ability for an end-user to perform a given operation= on an object under the control of a RS

    attribute: proper= ty related to an end-user

     

    [FI] I l= ike your proposal in general. There might be some discussions on the details= . I don't think it makes sense to grant "attributes".  <= /span> 

    Some explanations: a "rig= ht" is able to support a capability scheme. An "attribute" is= able to support an ACL scheme.

    These two schemes are ab= le to support "discretionary access control" where the end-user ha= s a "need-to-know".

    However, some attributes a= re also able to support what  was called in the past "mandatory ac= cess control"; for example,

    if the end-user is clea= red to "top-secret / marketing strategy".

    &n= bsp;

    =

    Int= eract Server (IS) - this is a new proposed term

    =

    Manages the front-end interaction with the RO,= in order to gather its consent. Depending on the deployment model and the p= rivacy requirements,
    the IS may be a component of the AS, or may be dist= inct and managed by another party.

    Example : an IS usually involves a web interface accessed by RO th= rough a web browser.

    Not= e : an IS is not always required, especially if the access is granted throug= h automated policies.

    Using the ISO style for definitions, I propose:

    =

     

    Interaction Server (IS)
    component from the AS or server interfacing with an AS that manages the in= teractions with a RO, in order to gather its authorization    =

    Note : since the RO is an optional c= omponent, the IS is also an optional component.

     

    [FI] indeed IS is optional. note for myself when looking at R= O : why is RO optional ?  

    Client<= span style=3D'font-size:10.0pt;line-height:125%;font-family:"Arial",sans-serif= ;color:#24292E;font-weight:normal'>

    Reques= ts privileges from the AS, and uses access tokens at the RS. This specificat= ion differentiates between a specific instance (the client instance, identif= ied by its unique public key)
    and the software running the instance (the= client software). . For some kinds of client software, there could be many = instances of a single piece of client software.
    The AS determines which p= olicies apply to a given client instance, including what it can request and = on whose behalf.

    Some comments: The above text is stating: "(the client instance, identified by its unique public= key)".
    A client instance may use a public key, but that key is not= necessarily unique, in particular when there are multiple ASs.

    [FI] yes,= although when possible I would still consider a better practice to expose a= key to a specific AS and not to the entire set of available ASs. 

    Example : a cl= ient can be a mobile application or a web application (the client software) = that requires authorizations from the RO to retrieve content from various pr= otected APIs. The client instance may for instance refer to a specific versi= on of that client software.

    See on-g= oing discussion : https://github.com/ietf-wg-gnap/gnap-core-protoc= ol/pull/132 (client instance).

    Using the ISO style for definit= ions, I propose:

    Client: application u= sed by an end-user to interact with an AS or a RS

    Note: a client can be a mobile application or a web application [FI] for me those are ju= st examples, because there could me more (ex IoT device)

    [FI] you re= move the entire discussion on client instance / client software, is that on = purpose because you think it's not useful/right, or is it because of somethi= ng else? (maybe add your comment of the related issue)   

    = Resource Server (RS)

    Accepts valid access tokens from the client issued by the A= S and serves protected resources on behalf of the RO. There could be multipl= e RSs protected by the AS that the client may call.

    Example : a RS is often composed of protected = APIs that can be consumed by authorized client software.  <= /o:p>

    One comment: a RO is not neces= sarily involved. [FI] a bit hard to imagine, there's some kind of owner. Could you be more= explicit?

    Using the= ISO style for definitions, I propose:

    Resource Server (RS): = server that accepts valid access tokens from clients issued by one or more A= Ss which are used to grant or deny some requested operations

    Note: a RS is often composed of protected APIs that can be= consumed by clients.

     

    Resource Owner (RO)<= /span>

    Authorizes the reques= t to access a protected resource from the RS to the client. The RO may decid= e to remove its consent at any time.

    Note : the RO may be a physical person or may represent an or= ganization.

     

    Two comments: In order to avoid confusion with the end-user= consent, the word " authorization" is being used instead of "= ;consent". [FI] ok 

    It should be said that the = RO is an optional component. [FI] why? Using th= e ISO style for definitions, I propose:

    Resource Owner (RO): p= hysical person acting on its own or representing an organization that author= izes to clients operations on protected resources from a RS

    Note: The RO is an optional component that may interact eit= her with one RS or with one or more ASs ,e.g. using an IS.=

    = End-user =E2=80=93 this was previously Requesting Party RQ

    A physical person that operates an= d interacts with the client software.

    Note : the end-user may or may not be the same entity as th= e RO.

    The Note is slightly inco= rrect. the physical person may or may not be the same entity as the RO. [FI] I didn't understand your comment

    Using the ISO style for defini= tions, I propose:

    End-us= er :  physical person that operates and interacts with the client softw= are

    Note : that physical person may o= r may not be the same entity as the RO.

     

    Access Token

    A set of privileges delegated to the client instance for a specific end= -user. An access token is created by the AS, consumed and verified by the RS= , and issued to and carried by the client's end-user on behalf of the RO. Th= e contents and format of the access token are opaque to the client.

    Example : JWT is a commonly us= ed format.

    Note 1 : a= n access token generally has a limited duration, after which it may be refre= shed at a regular interval.

    Note 2 : an access token may be revoked at any time by the RO. =

    Note 3 : an access token may act as a capa= bility or require an additional authentication by binding to a key

    A fundamental point: the third sentence = from the definition states: "The contents a= nd format of the access token are opaque to the client".<= o:p>

    [FI] I'll ch= eck your other thread dedicated to that issue 

    See my other email sent today about "RS-Token Introspec= tion or RC-Token Introspection" where I conclude:

    =

    &n= bsp;     For end-users caring about their privacy (or fo= r systems willing to protect the user's privacy), access tokens should not b= e considered
     &n= bsp;    to be opaque to RCs nor to RSs and ASs should not sup= port Token Introspection, whether it is RS-Token Introspection or RC-Token I= ntrospection.

    The example and the other Notes above should be removed. If needed th= ey should be placed in the main body of the document.

    <= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'= >Using the ISO= style for definitions, I propose:

    Access Token : digitally signed data issued by an = Authorization Server (AS) and consumed by a Resource Server (RS)
     &= nbsp;            = ;           that contains = rights and/or attributes granted to a particular= end-user

     

    Grant

    The process by which the client re= quests and is given delegated access to the RS by the AS through the authori= ty of the RO.

    Using the ISO style for definitions, I propose:

    Gran= t: permission given to end-user to use a subset of his rights and/or his att= ributes at a specific time and for a specific duration

     

    Key

    A public cr= yptographic binding a request to the holder of a private key. Access tokens = and client instances can be associated with specific keys at a point in time= .

    Note : a key can be= rotated or revoked by its holder. The protocol supports the update of the k= ey information.

    &= quot;key" is a general term that is well understood and that does not n= eed to be defined. [FI] I really wouldn't bet on that. We can reuse an existing definition= but it is a central piece so we need to be explicit

    The "definitions" section is not intended to explain wha= t can be done with the term that is being defined. [FI] ok we can work on that
    Unti= l the word "key" is qualified using one or more other terms, this = definition should be removed.

     

    <= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

    Resource

    A protected API served by the = RS and accessed by the client if and only if access has been granted. Access= to this resource is delegated by the RO as part of the grant process.

    The second sentence of = the definition is not in accordance with the ISO style or definitions and fu= rthermore this second sentence should be removed since a RO is an optional e= lement.

     

    Using the ISO style for definitions, I propose:

    Resource: protected API served by a RS and accessed by a clie= nt, if and only if access is granted by an access token

    Subject Information

    Information about a subject= (usually a RO) that is returned directly to the client from the AS.<= o:p>

    Note : this information needs to = be unique.

     

    This definition exhib= its several problems:

    (1) The term "subject" is not defined.

    (2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

    (3) The No= te states : "this information needs to be unique". Does it mean un= ique for the AS ? globally unique ?

    This definition should be revisited. [FI] I agree (I myself had many questions here= )

    Denis

     

    My questions : <= /span>

    - probably we=E2=80=99d n= eed to define subject

    Subject : https://open-measure.a= tlassian.net/wiki/spaces/DIC/pages/67600697/Subject+Dictionary+Entry

    - might be useful to c= larify the relationship to what identity providers do  =

     

     

    Cheers

    <= div>

    Fabien

     

    &n= bsp;

     

     

     

    --
    TXAuth mailing lis= t
    TXAuth@ietf.orghttp= s://www.ietf.org/mailman/listinfo/txauth

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

    It could be the RO or a guardian for the RO so user is the= right term.
    Peace ..tom


    On Sun, Dec 13, 2020 at 10:42 AM Fabien Imbault <= ;fabien.imbault@gmail.com&g= t; wrote:
    Hi,=C2=A0

    Thanks for the feedback. Highly use= case specific seems a bit of an overstatement, I would say it is the=C2=A0= most common case. But I get your point.
    We've tried to be mor= e specific on end-user=C2=A0vs RO. In your proposal I guess the user you= 9;re referring to is the RO.=C2=A0

    I find the sugg= ested definition a bit convoluted, let's think about it a bit more.=C2= =A0

    Cheers
    Fabien


    On= Sun, Dec 13, 2020 at 7:04 PM Tom Jones <thomasclinganjones@gmail.com> wro= te:
    This definition is highly use case specific. It leaves out the possibi= lity of (eg) a self-issued identifier where the RP displays a request to th= e user on a web page, the user clicks the button and the result is that a w= allet on the user's device acting as the AS sends an access token to th= e RP (which is typically the client in an OAUTH sense.) The underlined part= is often incorrect.

    Client

    • Definition: application used by an end-user to i= nteract with an AS or a RS
    suggestion: Client, = an application that desires to get access privileges from a user to resourc= es on an RS, possibly by way of an AS.

    Peac= e ..tom
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000bc7f0205b65ffd7b-- From nobody Sun Dec 13 14:31:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BCA3A0B56 for ; Sun, 13 Dec 2020 14:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcrG9gQLwgTM for ; Sun, 13 Dec 2020 14:31:26 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516CC3A0B55 for ; Sun, 13 Dec 2020 14:31:26 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id q205so4394386oig.13 for ; Sun, 13 Dec 2020 14:31:26 -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=KuwWOPJWR5NanRn7F090Jj80fq4iZT29TnVURHa7Qtw=; b=gVYuOUrNlS3SHsAGVisj3FDH/M8wMqNxiYiU8lBNvEqNYXamIXDv8eI61MBYHwRWSO s9m/AJ0RbGQms99k8Vh6HMWv4bycK02Zvs1DjkL7eb/rsXAuD8zLnPaqcjsdX+JLyFUI 2GWm7VA8WtYQjIGcgzKcGCVGQDDEWHEmI9RLSTwav9z3F9NkeyB5NhnFF2n1E4NLS7Xy VtbQVtuYNz62gbo4q2JzZmTYvSOx99SZUuYZXdSklKGoJoLQZbOhj5WFWoIccrFEdGPx V1ROm2UB4hVovANzoTvSEpNdLJfGyAtph01tUzGuLprHyDEQw6LnLUvyC00tTgkFP2SL tWNA== 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=KuwWOPJWR5NanRn7F090Jj80fq4iZT29TnVURHa7Qtw=; b=QHUvw8aaoqh5M4dvokAO6rm6fT3nF/EEEXAg77XaYO/z0iHLX2qdlr4ikmhRmtF+kF l+rpjW4KBetfdiaAIzGA0CAB8bVJD5Qe3OC7VJz5JOPscqVX9Vx4YXZwYeMwp2gxQPX4 X8fCQcGYFPdI70TOLoXxAadMXrUrdttIgki5yxpyPqusu06CebFsxVavygUmGlH6pR1e 1vnOEriJ5Q7qicJPp8OhD43R1uvp/GkcPzoLiA+BubptiHbXuhz74bgWsyzTgcewsMFu H6V/TWTdSFa7THJ0kWCIODVe63wfh3ATQwUK/IHLLhOPC2wISZWlMI8iMz1SbUP4Ms4a wSfw== X-Gm-Message-State: AOAM5308kU92BRt6FKXcqZvUHq0K3X84w3hYn5jK8CNXwcaHzK7aKFeQ 51bu/LNRCbarPl+F8c31X+quGI059CG/Wd8RcJM= X-Google-Smtp-Source: ABdhPJzJctYqHtk/SCjmCmntfAivz4Rme2jHXuR/rVEM+aE8XeGDV+um6R2IZebj3JVGomOWzOz54Ekk+LdYo7WuV1s= X-Received: by 2002:aca:1109:: with SMTP id 9mr16846011oir.131.1607898685665; Sun, 13 Dec 2020 14:31:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Jones Date: Sun, 13 Dec 2020 14:31:14 -0800 Message-ID: To: Fabien Imbault Cc: Jim Willeke , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000fe742205b660151c" Archived-At: Subject: Re: [GNAP] physical person 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, 13 Dec 2020 22:31:28 -0000 --000000000000fe742205b660151c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable agree w/ Fabien on that point. My own preference would be to call the RO an entity, which means a named object. Peace ..tom On Sun, Dec 13, 2020 at 12:23 PM Fabien Imbault wrote: > Hi, > > Yes. > > For end user at least, we wanted to convey that it is a real person. > > The case is different for the RO, indeed here person would be enough I > believe. > > Fabien > > > Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke a = =C3=A9crit : > >> A natural person is usually implied to be a Human Being. >> As in jurisprudence, fundamental human rights are implicitly granted onl= y >> to Natural Persons. >> >> A person or entity seems to be more appropriate. >> >> -- >> -jim >> Jim Willeke >> >> >> On Sun, Dec 13, 2020 at 1:44 PM Fabien Imbault >> wrote: >> >>> Hi, >>> >>> Wasn't thinking about that, but yes. >>> Natural person would be good. I change it in the wiki. >>> >>> Thxs >>> Fabien >>> >>> On Sun, Dec 13, 2020 at 7:07 PM Tom Jones >>> wrote: >>> >>>> I dislike this. A robot can be a physical person. What's wrong with >>>> natural person that others use? >>>> Peace ..tom >>>> -- >>>> TXAuth mailing list >>>> TXAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> TXAuth mailing list >>> TXAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> TXAuth mailing list >> TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fe742205b660151c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    agree w/ Fabien on that point.=C2=A0 My own preference wou= ld be to call the RO an entity, which means a named object.
    Peace ..tom


    On S= un, Dec 13, 2020 at 12:23 PM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi,

    Yes.=C2=A0

    For end user at least, we wanted to convey tha= t it is a real person.=C2=A0

    The case is different for the RO, indeed here person would be enough I= believe.=C2=A0

    Fabien

    Le dim. 13 d=C3=A9c. 2020 =C3=A0 21:20, Jim Willeke <jim@willeke.com> a= =C3=A9crit=C2=A0:
    A natural person is usually implied to be a Human Being= .
    As in jurisprudence, fundam= ental human rights are implicitly granted only to Natural Persons.

    = A person or entity seems to be more appropri= ate.

    --
    -jim
    Jim Willeke


    On Sun, Dec 13,= 2020 at 1:44 PM Fabien Imbault <fabien.imbault@gmail.com> = wrote:
    Hi,=C2=A0

    Wasn't thinking=C2=A0about that, = but yes.
    Natural person would be good. I change it in the wiki.= =C2=A0

    Thxs
    Fabien

    On Sun, Dec 13, = 2020 at 7:07 PM Tom Jones <thomasclinganjones@gmail.com>= ; wrote:
    I dislike this. A rob= ot can be a physical person. What's wrong with natural person that othe= rs use?
    Peace ..tom
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXA= uth@ietf.org
    https://www.ietf.org/mailman/listinfo/txauth<= /a>
    --
    TXAuth mailing list
    TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
    --000000000000fe742205b660151c-- From nobody Sun Dec 13 14:34:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA43A0B6C for ; Sun, 13 Dec 2020 14:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh7xu75spa4u for ; Sun, 13 Dec 2020 14:34:36 -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 243C73A0CFE for ; Sun, 13 Dec 2020 14:34:36 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id s75so17156768oih.1 for ; Sun, 13 Dec 2020 14:34:36 -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=uOYar20fIFMHR5KWl0c683PCcJGz7RV8vZafu5zPw3g=; b=B0tRTOTAOLNzsqoMDO42hS4ra2OhA/lcytExZsaRShCIBto7U4xl9e6tmYGPxkVKCG +H+ntwsbLJbFZXW1vvmmDQDnCDKSU8Jxm0asTCtOxj1wV6VUlncYBGBlE+qCJeRcZ6fW SyRIA1o4rg06nTm7uwE888vJ1NWghQnVb+eiWS8KEQqhBNZ8TXbMKxCZgsk+6rDbul08 iUPverxFRC6YO9nmhITrOeeJLJ5KpNdx3uT+X3H+oDBJFbe5P1SnSDwCylIstMgQUaiY rqeDvP2gmYUyOxGPXFggLOn8PVDL1m233DOHM5tS2hXfPPjdiQsRGWNrB3ozTmGXAOx8 3t8A== 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=uOYar20fIFMHR5KWl0c683PCcJGz7RV8vZafu5zPw3g=; b=pW66JVf1RBaNAGSYmEZ+4QBZGyO+Q3pjZHpAXK9qnBOZC81D5rU+g4dg1eaR1h08kz 0xEfRCcb2r31zwG8BZRTsJWJfT++qVfdNKTVHQi5Z5RHcFHt2soE3xHDHKhqvIhvdecQ 2O4SsJDCmDNPPK5iaiM2pTgkpAVcsIpwOvF464rn/7Kp41j37s8ei20bqAfgSy5qh2Lk NIrR0bkG4XsBDgDEkzngy7pO1pwz2+lM9aWrFyvYSgXoH31WyTZZ/z7M4O0Rr7ieUUBN 3hqJ6xmX2jDBNL9K5wvpE7TWFIDsMzOjuTj9TFt/dEB6w4M94LX+ZjgAKlA9hvk5DvqI +Nqg== X-Gm-Message-State: AOAM531b5+61i3fRfdXNw1SbbSm929LrW3exQjVIzaIp/7qT9sL9NemS X7SFbKDn3zjPtW+r84YqOPFQC5yZpWq0w8Ql9f0= X-Google-Smtp-Source: ABdhPJzHodnZ8CpeFSo5DXkuF5TyhW5udZSiUz0gB9vKjWQEevptOcrEZukDO9dcLhnxlQv8MNbFzb5OGTNbENX/waY= X-Received: by 2002:aca:470e:: with SMTP id u14mr15986519oia.172.1607898875328; Sun, 13 Dec 2020 14:34:35 -0800 (PST) MIME-Version: 1.0 References: <26b4f31f-921c-6f9e-57d9-e378406e4cb6@free.fr> <95C942E8-5261-4DA3-9764-27767B6E6BF1@gmail.com> <13422918-A279-45FD-97B7-E02D74534960@gmail.com> In-Reply-To: From: Tom Jones Date: Sun, 13 Dec 2020 14:34:22 -0800 Message-ID: To: Fabien Imbault Cc: Yaron Sheffer , Denis , GNAP Mailing List Content-Type: multipart/alternative; boundary="0000000000004c7bee05b66021e6" Archived-At: Subject: Re: [GNAP] Terminology proposal 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, 13 Dec 2020 22:34:41 -0000 --0000000000004c7bee05b66021e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable from the point of view of the GNAP std I would drop typically. If it meets the std then it MUST get an access token. It is the AS that is optional (at least i think that is where GNAP is headed.) Peace ..tom On Sun, Dec 13, 2020 at 11:21 AM Fabien Imbault wrote: > Hi Yaron, > > Stylistic comments are very important too. And at some point we'll need a > review from native english speakers in the group (I'm sure Justin and Aar= on > will be of great help here). > > Just wondering: what do you mean by "typically"? (ideally I'd rather have > a definition which is not dependent on use case). > > As soon as we land on something, I'll update the wiki. > > Fabien > > > > On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer > wrote: > >> It=E2=80=99s purely stylistic, but I find the definition of RS (=E2=80= =9Cserver that >> denies operations=E2=80=9D) a bit funny. How about: >> >> >> Resource Server (RS) >> >> - Definition: server that provides operations on protected resources; >> such operations typically require that the client provide valid acces= s >> tokens issued by an AS >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Fabien Imbault >> *Date: *Sunday, December 13, 2020 at 13:20 >> *To: *Yaron Sheffer >> *Cc: *Denis , GNAP Mailing List >> *Subject: *Re: [GNAP] Terminology proposal >> >> >> >> Hello everyone, >> >> >> >> We're at the end of the 2 week period, and so I integrated the various >> feedbacks : >> >> >> >> a) from Yaron's feedback, removed new term "IS" and update issue >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle >> the proposal here >> >> b) integrated Tom's feedback regarding the RO (and moved to access toke= n) >> >> c) definitions follow an ISO style as suggested by Denis, which we took >> as a starting point (but I made the modifications I felt were necessary) >> >> >> >> I modified the definitions, notes and examples as a consequence. You'll >> also find a summary of discussions for each term, so that we can keep tr= ack >> of them too. >> >> >> >> My biggest question is : what should we use as our main vocabulary >> between privilege/rights/attribute? I tried to clarify, please let me kn= ow >> what you think. The general idea is that we grant privileges that are >> delivered under the form of access tokens (which contain rights and/or >> attributes). >> >> Regarding whether access tokens should be opaque or not, I suggest to >> remove that from the definition and handle that in issue >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145 >> >> >> >> All has been consolidated on the wiki too >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so >> that we have a clearer view of where we stand. >> >> >> >> Please comment further on the list if you have comments, I'll update if >> necessary (and refer to the mailing list url in the comment of the wiki >> update, from now on). Then editors will review the proposal. >> >> Here is a copy of >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology#late= st-discussion-update >> . >> >> >> Latest discussion update >> >> Here we consolidate the latest proposal(s) from the group. We also >> include the discussion items (individual feedbacks). >> Authorization Server (AS) >> >> - Definition: server that grants privileges to a particular end-user >> and that provides them to a client in the form of an access token >> >> Feedbacks / discussion / questions : >> >> - Suggested "privilege" definition (that we would probably add as an >> additional sub-entry): "A privilege is the right to perform an operat= ion >> (or action) on a Resource." See also other def >> >> - Note that we don't include claims in the definition (cf OIDC/SSI >> integration), but since we talk about a "particular end-user" it is a= ssumed >> somehow >> - Denis suggested we used "rights and attributes" instead of >> privileges. [FI] However i don't think one can really speak about gra= nting >> attributes, except indirectly (ABAC). See access token for more on th= at, >> where we can be more specific. >> - Do we allow cases such as distributing the AS on a mobile? (in this >> case we're at the limit of what we call a server) >> >> Client >> >> - Definition: application used by an end-user to interact with an AS >> or a RS >> - Note: this specification differentiates between a specific instance >> (the client instance, identified by its public key) and the software >> running the instance (the client software). For some kinds of client >> software, there could be many instances of a single piece of client >> software. >> - Example: a client can be a mobile application, a web application, >> etc. >> >> Feedbacks / discussion : >> >> - Replaces previously proposed RC, we wouldn't provide a short name. >> - Keep OAuth2 term, but we clarify it >> - Further discussion on Client instance >> >> >> Resource Server (RS) >> >> - Definition: server that denies operations on protected resources, >> unless the client provides valid access tokens issued by an AS >> >> Feedbacks / discussion : >> >> - Denis suggests to make explicit that we could have several ASs - >> "issued by one or more ASs" (also we'd need a convention on how to de= note >> plural, e.g. ASs). Not exactly sure right now of the multiple issuanc= e >> would work, so needs to be clarified. Also not sure if that's even >> necessary (do we lack in generality if we keep the singular?) >> >> Resource Owner (RO) >> >> - Definition: physical person acting on its own or representing an >> organization, that may grant privileges on resources he has authority= upon >> - Note: the act of granting privileges may be manual (i.e. through an >> interaction) or automatic (i.e. through predefined rules). >> >> Feedbacks / discussion >> >> - As some point we suggested "The RO may decide to remove its consent >> at any time." Tom provided useful feedback >> on >> that. Moved to access token where it fits more naturally. >> >> End-user >> >> - Definition: physical person that operates with the client software >> - Note: that physical person may or may not be the same entity as the >> RO >> >> Access token >> >> - Definition: digitally signed data that contains specific rights >> and/or attributes >> - Note 1: the access token can be issued to an end-user (usually >> requiring his authentication) and subsequently refreshed. The AS usua= lly >> provides a method for the RO to revoke the privileges at any point in= time. >> - Note 2: an access token may act as a capability (i.e. bearer token) >> or require an additional authentication by binding to a key (i.e. bou= nd >> token) >> >> Feedbacks / discussion >> >> - Would require the subdefinitions right: ability for an end-user to >> perform a given operation (or action) on a resource (or object) under= the >> control of a RS / attribute: property related to an end-user. >> - Note 2 is here in relationship with PR 129 >> >> >> Grant >> >> - Definition (verb): to permit, as a privilege given to an end-user >> to exercise some rights and/or assert attributes during a specific du= ration >> - Definition (noun): the act of granting >> >> Key >> >> - Definition: public cryptographic binding a request to the holder of >> a private key, used by the protocol entities (AS, RS, client instance= , >> bound token, etc.) to identify themselves. >> - Note: a key can be rotated or revoked by its holder. The protocol >> supports the update of the key information. >> >> Feedbacks / discussion >> >> - Denis thinks the term "key" is well understood and doesn't need to >> be defined. Yet, I tend to believe we'd gain to keep it. First the ge= neric >> term "key" may be many things : symmetric/asymmetric, public/private,= etc. >> It's also useful to explain its use in the protocol >> >> Resource >> >> - Definition: protected API served by a RS and accessed by a client, >> if and only if a valid access token is provided >> >> >> >> On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault >> wrote: >> >> Hi Yaron, >> >> >> >> Yes I highlighted that this was a new term. We can deal with it as a >> separate issue indeed. >> >> >> >> Best >> >> Fabien >> >> >> >> On Fri, Dec 11, 2020 at 6:02 PM Yaron Sheffer >> wrote: >> >> Hi Fabien, >> >> >> >> Yes, we definitely need to reach closure on terminology, thank you for >> driving this discussion! >> >> >> >> One process comment: unless I=E2=80=99m missing something, the Interact = (or >> Interaction) Server is not mentioned in the current draft. I suggest we = do >> not introduce new functional components or new behaviors as part of the >> terminology discussion. Specifically, if the IS is useful, let=E2=80=99s= reach >> consensus on that separately. Then we can add it into the Terminology >> section. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *TXAuth on behalf of Fabien Imbault < >> fabien.imbault@gmail.com> >> *Date: *Friday, December 11, 2020 at 14:31 >> *To: *Denis >> *Cc: *GNAP Mailing List >> *Subject: *Re: [GNAP] Terminology proposal >> >> >> >> Hi Denis, >> >> >> >> Thanks for your detailed feedback. My comments are embedded into your >> message. Again those comments are my own, and we'll need to converge to >> some consensus beyond what I say here. My main open question is really >> about the RO being optional. Could you explain? >> >> >> >> Fabien >> >> >> >> On Fri, Dec 11, 2020 at 12:08 PM Denis wrote: >> >> This is a global response to the definitions proposal. >> >> >> TerminologyI propose to adopt the way ISO defines how to write the >> definitions.It is a *single sentence* that may be substituted to the >> wording being defined in the context of a sentence that uses that >> definition. >> Since this single sentence can be substituted to the wording, there is >> not point at the end of that sentence. The sentence does not >> have a "a" or "the" in front of it. >> >> >> >> [FI] In the first version, I was mostly trying to not get too far away >> from the current text. But yes that's a good idea, it gives a more >> formal rule, which has been proven to work. >> >> >> >> If more information is useful to understand the wording, it is placed in >> one or more notes afterwards. >> >> >> >> Note: The ISO rules for drafting definitions are in the ISO/IEC >> Directives, Part 2 (edition 2018): >> >> 16.5.6 Definitions >> >> The definition shall be written in such a form that it can replace the >> term in its context. It shall not start with an article (=E2=80=9Cthe=E2= =80=9D, =E2=80=9Ca=E2=80=9D) nor >> end with a full stop. >> A definition shall not take the form of, or contain, a requirement. >> >> Only one definition per terminological entry is allowed. If a term is >> used to define more than one concept, a separate terminological entry sh= all >> be created >> for each concept and the domain shall be included in angle brackets >> before the definition. >> >> Circular definitions, which repeat the term being defined, are not >> allowed. >> >> Comments are inserted between the lines. >> >> >> >> Hello everyone, >> >> >> >> As an editor : a quick reminder that terminology issues will be discusse= d >> in the coming weeks, and we're expecting your inputs right now (accordin= g >> to the process previously sent on the mailing list). >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/29 >> >> https://github.com/ietf-wg-gnap/gnap-core-protocol/wiki/Terminology >> >> >> >> The rest of this message is a proposal written in my own name, and >> doesn't involve discussions with the editors/chairs who might have >> different opinions. >> Authorization Server (AS) >> >> Manages the granting of privileges to a third-party client instance. If >> the RO consents to at least a part of what is requested, the AS issues a= n >> access token to the client. >> >> *My questions: * >> >> *- was else do we issue? (e.g. id claims, payment info, etc.) We could >> have more than access tokens, but =E2=80=9Cdirected information=E2=80=9D= is not clear. I >> removed that for now.* >> >> *- there might potentially be several AS, currently we don=E2=80=99t ref= lect that >> anywhere. If would leave that as an open item, depending on what we end = up >> doing in the spec* >> >> I am not in favour of this definition: A RO as defined later: "authorize= s >> the request to access a protected resource from the RS to the client". >> This does not mean in any way that a RO has necessarily a direct >> relationship with one or more ASs. [FI] indeed we could remove that >> limitation, to have a more general definition >> Using the ISO style for definitions, I propose: >> >> Authorization Server (AS): server that grants rights and/or attributes t= o >> a particular end-user and that provides them to a client in the form of = an >> access token >> >> Since this definition is using the words "rights" and "attributes", >> these two terms need to be defined as well. >> >> right: ability for an end-user to perform a given operation on an object >> under the control of a RS >> >> attribute: property related to an end-user >> >> >> >> [FI] I like your proposal in general. There might be some discussions on >> the details. I don't think it makes sense to grant "attributes". >> >> Some explanations: a "right" is able to support a capability scheme. An >> "attribute" is able to support an ACL scheme. >> >> These two schemes are able to support "discretionary access control" >> where the end-user has a "need-to-know". >> >> However, some attributes are also able to support what was called in th= e >> past "mandatory access control"; for example, >> >> if the end-user is cleared to "top-secret / marketing strategy". >> >> >> >> Interact Server (IS) - this is a new proposed term >> >> Manages the front-end interaction with the RO, in order to gather its >> consent. Depending on the deployment model and the privacy requirements, >> the IS may be a component of the AS, or may be distinct and managed by >> another party. >> >> Example : an IS usually involves a web interface accessed by RO through = a >> web browser. >> >> Note : an IS is not always required, especially if the access is granted >> through automated policies. >> >> Using the ISO style for definitions, I propose: >> >> >> >> Interact*ion* Server (IS) >> >> component from the AS or server interfacing with an AS that manages the >> interactions with a RO, in order to gather its authorizationNote : since >> the RO is an optional component, the IS is also an optional component. >> >> >> >> [FI] indeed IS is optional. note for myself when looking at RO : why is >> RO optional ? >> >> Client Requests privileges from the AS, and uses access tokens at the >> RS. This specification differentiates between a specific instance (the >> client instance, identified by its unique public key) >> and the software running the instance (the client software). . For some >> kinds of client software, there could be many instances of a single piec= e >> of client software. >> The AS determines which policies apply to a given client instance, >> including what it can request and on whose behalf. >> >> Some comments: The above text is stating: "(the client instance, >> identified by its unique public key)". >> A client instance may use a public key, but that key is not necessarily >> unique, in particular when there are multiple ASs. >> >> [FI] yes, although when possible I would still consider a better practic= e >> to expose a key to a specific AS and not to the entire set of available >> ASs. >> >> Example : a client can be a mobile application or a web application (the >> client software) that requires authorizations from the RO to retrieve >> content from various protected APIs. The client instance may for instanc= e >> refer to a specific version of that client software. >> >> *See on-going discussion : >> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/132 >> (client >> instance). * >> >> Using the ISO style for definitions, I propose: >> >> Client: application used by an end-user to interact with an AS or a RS >> >> Note: a client can be a mobile application or a web application [FI] for >> me those are just examples, because there could me more (ex IoT device) >> >> [FI] you remove the entire discussion on client instance / client >> software, is that on purpose because you think it's not useful/right, or= is >> it because of something else? (maybe add your comment of the related >> issue) >> >> Resource Server (RS) >> >> Accepts valid access tokens from the client issued by the AS and serves >> protected resources on behalf of the RO. There could be multiple RSs >> protected by the AS that the client may call. >> >> Example : a RS is often composed of protected APIs that can be consumed >> by authorized client software. >> >> One comment: a RO is not necessarily involved. [FI] a bit hard to >> imagine, there's some kind of owner. Could you be more explicit? >> Using the ISO style for definitions, I propose: >> >> Resource Server (RS): server that accepts valid access tokens from >> clients issued by one or more ASs which are used to grant or deny some >> requested operations >> >> Note: a RS is often composed of protected APIs that can be consumed by >> clients. >> >> >> >> Resource Owner (RO) >> >> Authorizes the request to access a protected resource from the RS to the >> client. The RO may decide to remove its consent at any time. >> >> Note : the RO may be a physical person or may represent an organization. >> >> >> >> Two comments: In order to avoid confusion with the end-user consent, the >> word " authorization" is being used instead of "consent". [FI] ok >> >> It should be said that the RO is an optional component. [FI] why? Using >> the ISO style for definitions, I propose: >> >> Resource Owner (RO): physical person acting on its own or representing a= n >> organization that authorizes to clients operations on protected resource= s >> from a RS >> >> Note: The RO is an optional component that may interact either with one >> RS or with one or more ASs ,e.g. using an IS. >> >> End-user =E2=80=93 this was previously Requesting Party RQ >> >> A physical person that operates and interacts with the client software. >> >> Note : the end-user may or may not be the same entity as the RO. >> >> The Note is slightly incorrect. the *physical person* may or may not be >> the same entity as the RO. [FI] I didn't understand your comment >> Using the ISO style for definitions, I propose: >> >> End-user : physical person that operates and interacts with the client >> software >> >> Note : that physical person may or may not be the same entity as the RO. >> >> >> >> Access Token >> >> A set of privileges delegated to the client instance for a specific >> end-user. An access token is created by the AS, consumed and verified by >> the RS, and issued to and carried by the client's end-user on behalf of = the >> RO. The contents and format of the access token are opaque to the client= . >> >> Example : JWT is a commonly used format. >> >> Note 1 : an access token generally has a limited duration, after which i= t >> may be refreshed at a regular interval. >> >> Note 2 : an access token may be revoked at any time by the RO. >> >> Note 3 : an access token may act as a capability or require an additiona= l >> authentication by binding to a key >> >> A fundamental point: the third sentence from the definition states: "The >> contents and format of the access token are opaque to the client". >> >> [FI] I'll check your other thread dedicated to that issue >> >> See my other email sent today about "RS-Token Introspection or RC-Token >> Introspection" where I conclude: >> >> For end-users caring about their privacy (or for systems willing t= o >> protect the user's privacy), access tokens should not be considered >> to be opaque to RCs nor to RSs and ASs should not support Token >> Introspection, whether it is RS-Token Introspection or RC-Token >> Introspection. >> >> The example and the other Notes above should be removed. If needed they >> should be placed in the main body of the document. >> >> Using the ISO style for definitions, I propose: >> >> Access Token : digitally signed data issued by an Authorization Server >> (AS) and consumed by a Resource Server (RS) >> that contains rights and/or attributes granted >> to a particular end-user >> >> >> >> Grant >> >> The process by which the client requests and is given delegated access t= o >> the RS by the AS through the authority of the RO. >> >> Using the ISO style for definitions, I propose: >> >> Grant: permission given to end-user to use a subset of his rights and/or >> his attributes at a specific time and for a specific duration >> >> >> >> Key >> >> A public cryptographic binding a request to the holder of a private key. >> Access tokens and client instances can be associated with specific keys = at >> a point in time. >> >> Note : a key can be rotated or revoked by its holder. The protocol >> supports the update of the key information. >> >> "key" is a general term that is well understood and that does not need t= o >> be defined. [FI] I really wouldn't bet on that. We can reuse an existing >> definition but it is a central piece so we need to be explicit >> >> The "definitions" section is not intended to explain what can be done >> with the term that is being defined. [FI] ok we can work on that >> Until the word "key" is qualified using one or more other terms, this >> definition should be removed. >> >> >> >> Resource >> >> A protected API served by the RS and accessed by the client if and only >> if access has been granted. Access to this resource is delegated by the = RO >> as part of the grant process. >> >> The second sentence of the definition is not in accordance with the ISO >> style or definitions and furthermore this second sentence should be remo= ved >> since a RO is an optional element. >> >> >> Using the ISO style for definitions, I propose: >> >> Resource: protected API served by a RS and accessed by a client, if and >> only if access is granted by an access token >> >> Subject Information >> >> Information about a subject (usually a RO) that is returned directly to >> the client from the AS. >> >> Note : this information needs to be unique. >> >> >> >> This definition exhibits several problems: >> >> (1) The term "subject" is not defined. >> >> (2) The information that is returned is for an end-user, i.e. not for "(= usually >> a RO)". >> >> (3) The Note states : "this information needs to be unique". Does it mea= n >> unique for the AS ? globally unique ? >> >> This definition should be revisited. [FI] I agree (I myself had many >> questions here) >> >> Denis >> >> >> >> *My questions : * >> >> *- probably we=E2=80=99d need to define subject* >> >> *Subject : >> https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subjec= t+Dictionary+Entry >> * >> >> *- might be useful to clarify the relationship to what identity provider= s >> do * >> >> >> >> >> >> 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 > --0000000000004c7bee05b66021e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    from the point of view of the GNAP std I would drop typica= lly. If it meets the std then it MUST get an access token. It is the AS tha= t is optional (at least i think that is where GNAP is headed.)
    Peace ..tom

    <= /div>
    O= n Sun, Dec 13, 2020 at 11:21 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
    Hi Yaron,=C2=A0

    Stylistic comments are very important= too. And at some point we'll need a review from native english speaker= s in=C2=A0the group (I'm sure Justin and Aaron will be of great=C2=A0he= lp here).

    Just wondering: what do you mean by &quo= t;typically"? (ideally I'd rather have a definition which is not d= ependent on use case).

    As soon as we land on somet= hing, I'll update the wiki.

    Fabien
    <= br>


    On Sun, Dec 13, 2020 at 8:12 PM Yaron Sheffer <<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com> wrote:

    It=E2=80=99s purely sty= listic, but I find the definition of RS (=E2=80=9Cserver that denies operat= ions=E2=80=9D) a bit funny. How about:

    =C2=A0

    Resource Server (RS)

    • Definition: server that provides operations on pr= otected resources; such operations typically require that the client provid= e valid access tokens issued by an AS

    Thanks,

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

    =C2=A0

    From: Fabien Imbault <fabien.imbault@gmail.com>
    = Date: Sunday, December 13, 2020 at 13:20
    To: Yaron Sheffer= <yaronf.ietf= @gmail.com>
    Cc: Denis <denis.ietf@free.fr>, GNAP Mailing List <<= a href=3D"mailto:txauth@ietf.org" target=3D"_blank">txauth@ietf.org>=
    Subject: Re: [GNAP] Terminology proposal

    =C2=A0

    Hello everyone,=C2=A0

    =C2=A0

    We'= re at the end of the 2 week period, and so I integrated the various feedbac= ks :=C2=A0

    =C2=A0=

    a) from Yaron's feedback, = removed new term "IS" and update issue=C2=A0http= s://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133 to handle the= proposal here=C2=A0

    b) = integrated Tom's feedback regarding the RO (and moved=C2=A0 to access t= oken)

    c) definitions fol= low an ISO style as suggested by Denis, which we took as a starting point (= but I made the=C2=A0modifications I felt were necessary)

    <= /div>

    =C2=A0

    I modified the definitions, notes and examples as a consequ= ence. You'll also find a summary of discussions for each term, so that = we can keep track of them too.

    =C2=A0

    My biggest= question is : what should we use as our main vocabulary between privilege/= rights/attribute? I tried to clarify, please let me know what you think. Th= e general idea is that we grant privileges that are delivered under the for= m of access tokens (which contain rights and/or attributes).<= /p>

    Regarding whether access tokens should= be opaque or not, I suggest to remove that from the definition and handle = that in issue=C2=A0https://github.com/ietf-wg-gnap/gnap-co= re-protocol/issues/145

    =C2=A0

    All has been c= onsolidated on the wiki too=C2=A0https://github.com/= ietf-wg-gnap/gnap-core-protocol/wiki/Terminology so that we have a clea= rer view of where we stand.=C2=A0

    =C2=A0

    Please = comment further on the list if you have comments,=C2=A0I'll update if n= ecessary (and refer to the mailing list url in the comment of the wiki upda= te, from now on). Then editors will review the proposal.=C2=A0

    =C2=A0

    Latest discussion update

    <= span style=3D"font-size:12pt;font-family:"Segoe UI",sans-serif;co= lor:rgb(36,41,46)">Here we consolidate the latest proposal(s) from the grou= p. We also include the discussion items (individual feedbacks).

    Authorization Server (AS)

    • Definition: server that grants privileges to a pa= rticular end-user and that provides them to a client in the form of an acce= ss token

    Fee= dbacks / discussion / questions :

    • Suggested "privilege" definition (that we would probably add a= s an additional sub-entry): "A privilege is the right to perform an op= eration (or action) on a Resource." See also=C2=A0other def
    • Note that we don't include claims in the definition (cf OIDC/SS= I integration), but since we talk about a "particular end-user" i= t is assumed somehow
    • Denis sugge= sted we used "rights and attributes" instead of privileges. [FI] = However i don't think one can really speak about granting attributes, e= xcept indirectly (ABAC). See access token for more on that, where we can be= more specific.
    • Do we allow cases = such as distributing the AS on a mobile? (in this case we're at the lim= it of what we call a server)

  • Definition: applicatio= n used by an end-user to interact with an AS or a RS
  • Note: this specification differentiates between a specif= ic instance (the client instance, identified by its public key) and the sof= tware running the instance (the client software). For some kinds of client = software, there could be many instances of a single piece of client softwar= e.
  • Example: a client can be a mobi= le application, a web application, etc.

    • Feedbacks / discussion :
    • Replaces previously proposed RC, we wouldn't prov= ide a short name.
    • Keep OAuth2 term= , but we clarify it
    • Further dis= cussion on=C2=A0Client instance

    Resource Server (RS)

    • Definition: server that denies operations on protected resour= ces, unless the client provides valid access tokens issued by an AS<= u>

    Feedbacks / discuss= ion :

    • Denis suggests to make ex= plicit that we could have several ASs - "issued by one or more ASs&quo= t; (also we'd need a convention on how to denote plural, e.g. ASs). Not= exactly sure right now of the multiple issuance would work, so needs to be= clarified. Also not sure if that's even necessary (do we lack in gener= ality if we keep the singular?)

    = Resource Owner (RO)

    • Defini= tion: physical person acting on its own or representing an organization, th= at may grant privileges on resources he has authority upon
    • Note: the act of granting privileges may be manual= (i.e. through an interaction) or automatic (i.e. through predefined rules)= .

    Feedbacks = / discussion

    • As some point we s= uggested "The RO may decide to remove its consent at any time." T= om provided=C2=A0useful feedback=C2=A0on t= hat. Moved to access token where it fits more naturally.

    End-user

    • Definition: physical person that operates with the client software<= u>
    • Note: that physical person may or = may not be the same entity as the RO

    Access token

    • Definiti= on: digitally signed data that contains specific rights and/or attributes
    • Note 1: the access token can be iss= ued to an end-user (usually requiring his authentication) and subsequently = refreshed. The AS usually provides a method for the RO to revoke the privil= eges at any point in time.
    • Note 2:= an access token may act as a capability (i.e. bearer token) or require an = additional authentication by binding to a key (i.e. bound token)<= /u>

    Feedbacks / discussion=

    • Would require the subdefinit= ions right: ability for an end-user to perform a given operation (or action= ) on a resource (or object) under the control of a RS / attribute: property= related to an end-user.
    • Note 2 is= here in relationship with=C2=A0PR 129

    Grant

    • Definition (verb): to permit, as a privilege given to an end-user to = exercise some rights and/or assert attributes during a specific duration=
    • Definition (noun): the act of granti= ng

    Key=

    • Definition: public cryptographic binding a request = to the holder of a private key, used by the protocol entities (AS, RS, clie= nt instance, bound token, etc.) to identify themselves.
    • Note: a key can be rotated or revoked by its holder. = The protocol supports the update of the key information.

    Feedbacks / discussion<= u>

    • Denis thinks the term "key" = is well understood and doesn't need to be defined. Yet, I tend to belie= ve we'd gain to keep it. First the generic term "key" may be = many things : symmetric/asymmetric, public/private, etc. It's also usef= ul to explain its use in the protocol

    Resource

    • Definition:= protected API served by a RS and accessed by a client, if and only if a va= lid access token is provided

    =C2=A0

    On Fri, Dec 11, 2020 at 6:05 PM Fabien Imbault <fabien.imbault@gmail.com> wro= te:

    Hi Yaron,=C2=A0

    =C2= =A0

    Yes I highlighted that this= was a new term. We can deal with it as a separate issue indeed.=C2=A0

    =C2=A0

    Best

    Fabien

    =C2=A0

    On Fri, Dec 11, 2020 at= 6:02 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

    Hi Fabien,

    =C2=A0

    Yes, we definitely need to reach closure on terminology, thank you for dri= ving this discussion!

    =C2=A0=

    One process comment: unless I=E2=80=99m m= issing something, the Interact (or Interaction) Server is not mentioned in = the current draft. I suggest we do not introduce new functional components = or new behaviors as part of the terminology discussion. Specifically, if th= e IS is useful, let=E2=80=99s reach consensus on that separately. Then we c= an add it into the Terminology section.

    =C2=A0

    Thanks,

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

    =C2=A0

    From: TXAut= h <txauth-b= ounces@ietf.org> on behalf of Fabien Imbault <fabien.imbault@gmail.com>=
    Date: Friday, December 11, 2020 at 14:31
    To: Denis <= ;denis.ietf@free.fr= >
    Cc: GNAP Mailing List <txauth@ietf.org>
    Subject: Re: [GNAP= ] Terminology proposal

    =C2=A0

    Hi Den= is,=C2=A0

    =C2=A0=

    Thanks for your detailed feedback. My= comments are embedded into your message. Again those comments are my own, = and we'll need to converge to some consensus beyond what I say here. My= main open question is really about the RO being optional. Could you explai= n?

    =C2=A0<= /p>

    Fabien=C2=A0

    =C2=A0

    On Fri, Dec 11, 2020 at 12:08 PM Denis <denis.ietf@free.fr> wrote:

    This is a glob= al response to the definitions proposal.

    =C2=A0

    Terminology

    I propose to adopt the way ISO defines how= to write the definitions.

    It is a single sentence that may be substituted to the wording bein= g defined in the context of a sentence that uses that definition.
    Since= this single sentence can be substituted to the wording, there is not point= at the end of that sentence. The sentence does not
    have a "a"= ; or "the" in front of it.

    <= /blockquote>

    =C2=A0

    =

    [FI]=C2=A0In the first ver= sion, I was mostly trying to not get too far away from the current text.=C2=A0But=C2=A0yes that's a good idea, it gives a more formal rule, which has been = proven to work.=C2=A0

    =

    =C2=A0

    If more information is useful to understand the wording, it is placed = in one or more notes afterwards.

    =C2=A0

    Note: Th= e ISO rules for drafting definitions are in the ISO/IEC Directives, Part 2 = (edition 2018):

    16.5.6=C2=A0=C2=A0=C2=A0 Def= initions

    The definition shall be written i= n such a form that it can replace the term in its context. It shall not sta= rt with an article (=E2=80=9Cthe=E2=80=9D, =E2=80=9Ca=E2=80=9D) nor end wit= h a full stop.
    A definition shall not take the form of, or contain, a r= equirement.

    Only one definition per terminological entry is allowed.= If a term is used to define more than one concept, a separate terminologic= al entry shall be created
    for each concept and the domain shall be incl= uded in angle brackets before the definition.

    Circular definitions, = which repeat the term being defined, are not allowed.

    Comments are inserted between the lines.<= /p>

    =C2=A0

    = Hello everyone,=C2=A0

    =C2=A0<= u>

    As an editor : a quick r= eminder that terminology=C2=A0issues will be discussed in the coming weeks,= and we're expecting your inputs right now (according to the process pr= eviously sent on the mailing list).

    =C2= =A0

    The rest of this mes= sage is a proposal written in my own name, and doesn't involve discussi= ons with the editors/chairs who might have different opinions.=C2=A0

    Authorization Server (AS)

    <= p style=3D"margin-bottom:12.25pt;line-height:150%">Manages the granting of privileges= to a third-party client instance. If the RO consents to at least a part of= what is requested, the AS issues an access token to the client. =

    My questions: <= /span>

    - = was else do we issue? (e.g. id claims, payment info, etc.) We could have mo= re than access tokens, but =E2=80=9Cdirected information=E2=80=9D is not cl= ear. I removed that for now.

    - there might potentially be several AS, current= ly we don=E2=80=99t reflect that anywhere. If would leave that as an open i= tem, depending on what we end up doing in the spec=

    I am not in favour of thi= s definition: A RO as defined later: "authorizes the request to access= a protected resource from the RS to the client".
    This does not me= an in any way that a RO has necessarily a direct relationship with one or m= ore ASs.     [FI]= indeed we could remove that limitation, to have a more general definition<= /span>

    Using the ISO s= tyle for definitions, I propose:

    Authorization Se= rver (AS): server that grants rights and/or attributes to a particular end-= user and that provides them to a client in the form of an access token

    Since this definition is using the words = "rights" and "attributes= ", these two terms need to be defined as well.=

    right: abil= ity for an end-user to perform a given operation on an object under the con= trol of a RS

    attribute: property related to an end= -user

    =C2=A0

    [FI] I like your proposal in general. There might b= e some discussions on the details. I don't think it makes sense to gran= t "attributes".=C2=A0=C2=A0=C2=A0

    <= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in= 5pt 4.8pt">

    Some explanations: a "right" is able to support= a capability scheme. An "attribute" is able to support an ACL sc= heme.

    These two schemes are able to support &qu= ot;discretionary access control" where the end-user has a "need-t= o-know".

    However, some attributes are also a= ble to support what=C2=A0 was called in the past "mandatory access con= trol"; for example,

    if the end-user is clear= ed to "top-secret / marketing strategy".

    =

    =C2=A0

    Interact = Server (IS) - this is a new proposed term

    Manages the front-end interactio= n with the RO, in order to gather its consent. Depending on the deployment = model and the privacy requirements,
    the IS may be a component of the AS= , or may be distinct and managed by another party.

    =

    Example : an IS usually involves a = web interface accessed by RO through a web browser.

    Note : an IS is not always requir= ed, especially if the access is granted through automated policies.<= u>

    Using the ISO sty= le for definitions, I propose:

    =C2=A0

    Interaction Server (IS) <= br>
    component from the AS or server interfacing with an AS that manages = the interactions with a RO, in order to gather its authorization    <= /u>

    Note : since the RO is a= n optional component, the IS is also an optional component.

    =C2= =A0

    [FI] indeed IS is optional. note for myself when looking at RO : why = is RO optional ?=C2=A0=C2=A0

    Client

    Requests privileges from the AS, and uses access tokens at= the RS. This specification differentiates between a specific instance (the= client instance, identified by its unique public key)
    and the software= running the instance (the client software). . For some kinds of client sof= tware, there could be many instances of a single piece of client software.<= br>The AS determines which policies apply to a given client instance, inclu= ding what it can request and on whose behalf.

    Some comments: The= above text is stating: "(the clie= nt instance, identified by its unique public key)".
    A client insta= nce may use a public key, but that key is not necessarily unique, in partic= ular when there are multiple ASs.

    [FI] yes, a= lthough when possible I would still consider a better practice to expose a = key to a specific AS and not to the entire set of available ASs.=C2=A0

    Example : a client can be a mobile application or a web application (the c= lient software) that requires authorizations from the RO to retrieve conten= t from various protected APIs. The client instance may for instance refer t= o a specific version of that client software.

    See on-going discussion : https://github.c= om/ietf-wg-gnap/gnap-core-protocol/pull/132 (client instance). <= /i>

    Using the ISO style for definitions, I propose:=

    Client: application used by an end-user to interact wi= th an AS or a RS

    Note: a client can = be a mobile application or a web application [FI] for me those are just examples, becaus= e there could me more (ex IoT device)

    =

    [F= I] you remove the entire discussion on client instance / client software, i= s that on purpose because you think it's not useful/right, or is it bec= ause of something else? (maybe add your comment of the related issue)=C2=A0= =C2=A0

    Resource Server (RS)=

    Accepts valid = access tokens from the client issued by the AS and serves protected resourc= es on behalf of the RO. There could be multiple RSs protected by the AS tha= t the client may call.

    Example : a RS is often composed of protected APIs that can b= e consumed by authorized client software.=C2=A0

    One comment: a RO is not necess= arily involved. [FI] a bit hard to imagine, there's some kind of owner. Could you be= more explicit?

    Using the ISO style for definitions, I propose:

    <= blockquote style=3D"margin-top:5pt;margin-bottom:5pt">

    = Resource Server (RS): server that accepts valid access tokens from clients = issued by one or more ASs which are used to grant or deny some requested op= erations

    Note: a RS is often c= omposed of protected APIs that can be consumed by clients.=

    =C2=A0

    Resource Owner (RO)

    Authorizes the request to access a protected resour= ce from the RS to the client. The RO may decide to remove its consent at an= y time.

    N= ote : the RO may be a physical person or may represent an organization.

    =C2=A0=

    Two comments: In order to avoid conf= usion with the end-user consent, the word " authorization" is bei= ng used instead of "consent". [FI] ok=C2=A0

    It should be said that the RO is an optional component.= =C2=A0[FI] why? Using the ISO style for definitions, I pr= opose:

    Resource Owner (RO): physical person acting= on its own or representing an organization that authorizes to clients oper= ations on protected resources from a RS

    Note: The RO is an optional component that may interact either wi= th one RS or with one or more ASs ,e.g. using an IS.

    =

    End-user =E2=80=93 this was previously Requestin= g Party RQ

    A physical person that operates and interacts with the client software. =

    Note : t= he end-user may or may not be the same entity as the RO. <= /u>

    The Note is slightly incorrect. the physical person may or may not be the same entity as the RO. <= span style=3D"color:red">[FI] I didn't understand your comment

    Using the ISO st= yle for definitions, I propose:

    End-user :=C2=A0 physical person that operates and inter= acts with the client software

    Note : that physical person may or may not be the same entit= y as the RO.

    =C2=A0<= u>

    =

    = Access Token

    A set of privileges delegated to the client instance for a specific en= d-user. An access token is created by the AS, consumed and verified by the = RS, and issued to and carried by the client's end-user on behalf of the= RO. The contents and format of the access token are opaque to the client.<= /span>

    Example := JWT is a commonly used format.

    Note 1 : an access token generally has a limited du= ration, after which it may be refreshed at a regular interval.

    Note 2 : an access to= ken may be revoked at any time by the RO.

    Note 3 : an access token may act as a capability or require a= n additional authentication by binding to a key

    A fundamental point: the third sentence from the de= finition states: "The contents and= format of the access token are opaque to the client".

    [FI] I'll check your other thread dedicated to that issu= e=C2=A0

    See my other email= sent today about "RS-Token Introspection or RC-Token Introspection&qu= ot; where I conclude:

    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 For end-users caring about their privacy (or for systems willing to pro= tect the user's privacy), access tokens should not be considered=
    =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 to be opaque to RCs nor to RSs and ASs should not support Token Intr= ospection, whether it is RS-Token Introspection or RC-Token Introspection.<= /span>

    The= example and the other Notes above should be removed. If needed they should= be placed in the main body of the document.

    Using the ISO style for definitions, I propose:

    =

    Access Token : digital= ly signed data issued by an Authorization Server (AS) and consumed by a Res= ource Server (RS)
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 that contains rights= and/or attributes granted to a particular end-user    =

    =C2=A0

    Grant

    The process by whic= h the client requests and is given delegated access to the RS by the AS thr= ough the authority of the RO.

    Using the ISO style for definitions= , I propose:

    Grant: permission given to end-use= r to use a subset of his rights and/or his attributes at a specific time an= d for a specific duration

    =C2=A0

    Key

    A public cryptographic binding = a request to the holder of a private key. Access tokens and client instance= s can be associated with specific keys at a point in time.

    Note : a key can be rota= ted or revoked by its holder. The protocol supports the update of the key i= nformation.

    "key" is a general term that is well understood and that = does not need to be defined. [FI] I really wouldn't bet on that. We can reuse an exi= sting definition but it is a central piece so we need to be explicit=

    The "definitions" section = is not intended to explain what can be done with the term that is being def= ined. [FI] ok= we can work on thatUntil the word "key" is qual= ified using one or more other terms, this definition should be removed.

    =C2=A0

    Resource

    A protected API served by the RS and accessed by the cl= ient if and only if access has been granted. Access to this resource is del= egated by the RO as part of the grant process.

    The second sentence of the defini= tion is not in accordance with the ISO style or definitions and furthermore= this second sentence should be removed since a RO is an optional element.<= /span>

    =C2=A0

    Using the ISO style for definitions, I propose:

    Resource: protected API served by a RS and acc= essed by a client, if and only if access is granted by an access token

    Subject Information

    Information abou= t a subject (usually a RO) that is returned directly to the client from the= AS.

    Note : t= his information needs to be unique.

    =C2=A0

    This definition exhibits several proble= ms:

    (1) The term "subject" is not defined.

    (2) The information that is returned is for an end-user, i.e. not for "(usually a RO)".

    (3) The Note states : "this information needs to be uni= que". Does it mean unique for the AS ? globally unique ?

    This definition should be rev= isited. [FI] = I agree (I myself had many questions here)

    Denis=

    =C2=A0

    My questions : =

    - probably we=E2=80= =99d need to define subject

    Subject : https://open-measure.atlassian.net/wiki/spaces/DIC/pages/67600697/Subjec= t+Dictionary+Entry

    - might be useful to clarify the relationship to what iden= tity providers do=C2=A0

    =C2=A0

    =C2=A0

    Cheers

    Fabien

    <= /div>

    =C2=A0

    =C2=A0

    = =C2=A0

    =C2=A0

    =C2=A0

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

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