Re: [GNAP] GNAP Editors' Use of GitHub Issues

Yaron Sheffer <> Wed, 25 November 2020 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD9533A1537 for <>; Wed, 25 Nov 2020 10:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d0sC--ZMU-mS for <>; Wed, 25 Nov 2020 10:27:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5960A3A14FF for <>; Wed, 25 Nov 2020 10:27:44 -0800 (PST)
Received: by with SMTP id q16so3557339edv.10 for <>; Wed, 25 Nov 2020 10:27:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=IspZN1q2osmnlY5q72FJRN04XA6r1ALdL46bNTBTDnc=; b=ZIWjDmVFbIPb3TG4fX6g3cs0yMskb1igh4FuAQDVqPtOc1ejz7RF5vKwctrrZf8HJc DxDLeWy6INPqM2G4VCvEpMyOjMqjM4USe9k4T79B8r6TNYBVMOFHT8uwSyHpnO8gejE6 12C8QffUlSTIGZyiDHZmA26YUEjKRe78bvkR925BWdHzqWTviIJaKfvlCzNe3OhbB9mX m3S57tUrjO+FewPyA3d4WpaNFWnkXdGRq9w+p4xXiy4btWaUzblsjs4zYyAHHteH2BJu Y9Jvw7CdMUT0tsm3EHC1ZfZM+pbh1jy6PGzPqj4VvADUEQ97njJUtKEsipSoi7uSCJw/ y/qA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=IspZN1q2osmnlY5q72FJRN04XA6r1ALdL46bNTBTDnc=; b=qt2ywInVFkGuRl70sSId93/vcK1chJXCoPizonRgkQil08ZM2sN26CRvqODltFMGxl CdwhiOGWnqEV1etEwKic9ULutZ11hYAjoGnzMVk+rWXjE5XfY2m/4VOF7J/nolTmnWX4 rV/+XF8rWG+kqFAIqxD4oWKPpRB7uETydscT3NUoMZGSrwq6/67TXz2FeKNHmbw9sRyK EVuNAYdTKHmaFRT4pDfFNplxwZDg7mUDOFl/7riY3Zq5/M3W/G1jsQnSztmOMzLrBUyG PlZwqJYUtYnHQsYzJJpTrA8YuIm9ulJWVEQsRRx4SvJK8OiRPw/nlNT5P7rT0B6oV0Ui 8McQ==
X-Gm-Message-State: AOAM532Tpw/SBd+fLgfqptHMWF0E+/5RqQTM2wM22XiaKGxb4L+ZEeg0 jgiffqOIqllQUP0p2C0gZvgmzcjs6b4lWg==
X-Google-Smtp-Source: ABdhPJzdup5CZ9gFeQBll/J3qePSmNbCkvgwwfqUdWrQIPqJUdPF57DqUnGxVmw2CqTiGK4fgoFtPg==
X-Received: by 2002:a50:9b5c:: with SMTP id a28mr4767452edj.139.1606328862579; Wed, 25 Nov 2020 10:27:42 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id rs27sm1753271ejb.34.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2020 10:27:42 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.43.20110804
Date: Wed, 25 Nov 2020 20:27:40 +0200
From: Yaron Sheffer <>
To: Aaron Parecki <>, GNAP Mailing List <>
Message-ID: <>
Thread-Topic: [GNAP] GNAP Editors' Use of GitHub Issues
References: <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3689180861_211338390"
Archived-At: <>
Subject: Re: [GNAP] GNAP Editors' Use of GitHub Issues
X-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, 25 Nov 2020 18:27:49 -0000

Commenting on the proposed process (chair hat off):


I think “postponed” 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.


Moreover, IMO the label “postponed” is not actionable. Instead, I suggest to mark such issues with future milestones, e.g. “IETF110”, meaning that at this time we will review the issue. Otherwise, the “postponed” issues will probably suffer the destiny of all “low priority” issues – 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.








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


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.

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.


* Generic claim extension mechanism

Pending Merge:

* Make access token mandatory for continuation API calls

Postponed and Pending Close:

* Fetchable Keys
* Including OpenID Connect Claims
* Application communication with back-end
* Additional post-interaction protocols

Pending Close:
* HTTP PUT vs POST for rotating access tokens
* Use of hash with unique callback URL
* Interaction considerations
* Expanding dynamic reference handles
* Post interaction callback nonce
* Unique callback URIs 
* Instance identifier
* Requesting resources by reference
* Mapping resource references


Aaron Parecki


-- TXAuth mailing list