Re: [Txauth] New version of XYZ Draft

Dick Hardt <> Fri, 17 July 2020 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B7FE3A0AA1 for <>; Fri, 17 Jul 2020 15:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Status: No, score=-0.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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uhINNK34dYCK for <>; Fri, 17 Jul 2020 15:47:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AA373A0AA2 for <>; Fri, 17 Jul 2020 15:47:27 -0700 (PDT)
Received: by with SMTP id e4so14448156ljn.4 for <>; Fri, 17 Jul 2020 15:47:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fX+Uilvt+n3f6R5UmxF/5D6unCczKgXcFM+gAXBDoLg=; b=nmNLt8JN3+4OQMIDq+49pGhcohKNaIGIFfa+XTxl/kva6iuSJ7XmULaelozcgIIg/U j8cbdkqb5Mggy840BevAIWOb8py486HDyxc1008WqZwXxnL6ku57g5+kHNOG1UeQYgmV aLbzE/nCeXPkAFHNCap0AaconoWHPCT9RSdwrRUg87Gxmt38N42iJdGLnYp1szyeIA09 PfQQjab732l3p954TKalR8fUz22S6tgFCcmTYBb4LSUWh+bmFeo+eErHd44vUgWr0W/Z nCbJ2M6MlTVw2clqDySZhr53IPmPXo9OPyUdh8qGu/5XTzlZVVcwfvHjzdSL7meNfzRT tNKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fX+Uilvt+n3f6R5UmxF/5D6unCczKgXcFM+gAXBDoLg=; b=ECnsKf1VS41ARxGJIXu8zlSdEyxchi97cDMdIXlERwEYnPc/EkpMbLShaT3nxcmUsy 6YNJXIsgCEJ7Mr3F9knaChgLMpPkNPrIKEbrvn2p0hi72CIG87MnMUgAHmyKNPdP3/yM ThB75zDW2E0LDxWpkouHKAcUb4HP/eCUDiYt6NaOgX4wZdxeVsHUvzRKDsC1KOV010IA 1zXGEq6iLV7eweG7F5IZkEisLGlzs5xSBuBiujA3OyMFJ9nTxIaBs459e0NU/ipbf6kR jm/liFSgF0xdf1QQHQC9GlSMSRd4dGoeAZ3G65btxTvJAys7cxn9bYHG6EaHJh1uOprj yf2A==
X-Gm-Message-State: AOAM530V8+m8BaTksVtrX5rspcHoFbLripoY+v7W1KWzwcJU9xaCdX1L Jl+O5bAvUQoQC8H3bqfbVJ3leUATMZ/5+9KOvBM=
X-Google-Smtp-Source: ABdhPJwrkbE17IhxEVzygo2kXi4ML1gJItjQh0OTziY1gakpY9x/eKPrbTsXR22Z355Y0jFMaV5ZPB3lTrXJbE+7XFw=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr5435478ljo.142.1595026045143; Fri, 17 Jul 2020 15:47:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Fri, 17 Jul 2020 15:46:48 -0700
Message-ID: <>
To: Justin Richer <>
Content-Type: multipart/alternative; boundary="000000000000d40f3905aaaaf08a"
Archived-At: <>
Subject: Re: [Txauth] New version of XYZ Draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jul 2020 22:47:29 -0000

XYZ is looking a lot more like XAuth, similar to how XAuth has shifted
towards XYZ.

I have implemented separate URIs for grants and authorizations, and it
worked really well.

All 3 of the new capabilities are problematic. Perhaps you did not notice
that there no longer is a short_uri in XAuth? As I recall, you were opposed
to the short URI that was in the earlier drafts of XAuth. In my XAuth
implementation, I show QR codes in the CLI app. Have you checked out my
implementation? Have you implemented a QR code? I found that the string did
not need to be nearly as short as it has in the past.

I still don't understand the requirement to rotate the reference handle. I
read over the pointer you provided last time we discussed it, and
responded, but I have not heard back from you on that.


On Fri, Jul 17, 2020 at 2:36 PM Justin Richer <> wrote:

> Most of these are changes I’ve wanted to do for quite some time and
> finally had opportunity to make the edits. As I said below, the core
> protocol really hasn’t changed in nature, but hopefully it’s easier to
> understand with it laid out in this way.
> All of these are points that I’ve made previously on the list in
> discussions, but to answer your questions directly:
> - Mapping items to separate URLs has been on XYZ’s radar since well before
> it was proposed in Xauth, so this is bringing some of that into the
> concrete system. I still need to implement it to see how well it works in
> practice.
> - The need to rotate the reference handle as well as use it externally
> (the “extend a request” method) both call for having an identifier separate
> from the access URL. It also allows an AS more freedom in how it manages
> its endpoints, and aligns with the desire to push more information into the
> ongoing request after the initial phase. I’d actually rather the access
> token management move in that direction, using the token itself as the
> artifact, but I couldn’t do that and still use the DELETE method for
> revocation. So that’s an engineering challenge that I think the group
> should discuss, and decide whether it’s worth having the “DELETE” verb
> semantics and having that restriction placed on the AS as a consequence.
> - The DID work is likely better suited for an extension, and always has
> been. But it was worth having in previous revisions for discussion
> purposes, especially as a point around how a non-HTTP interaction method
> would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other interaction
> methods in the extensions landscape of GNAP, usable alongside the others.
> And a final point, the interaction setup hasn’t really changed, so I’m
> curious to hear what you think *has* changed there. Even with a couple
> new capabilities on the way there (short_uri and app) and back (pushback),
> It’s structurally and conceptually identical to previous revisions.
>  — Justin
> On Jul 17, 2020, at 1:10 PM, Dick Hardt <> wrote:
> Hey Justin,
> Glad to see that you are aligning on having URIs for the access tokens and
> the "grant".
> While the token URI is unique to the token, you have not done the same for
> a "grant", but have a handle and a non-unique URI.
> Why not have a unique grant URI similar to the token URI? (a combination
> of the handle and a non-unique URI) -- this is then both the identifier,
> and the URL for "management"?
> Glad to see you have excised the DID references. I don't think the common
> use cases are well established there currently.
> I have LOTS of feedback on your interaction changes, that I'll post later
> on, and hope that others have feedback on those as well.
> /Dick
> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer <> wrote:
>> Hi all,
>> I’ve updated the XYZ draft specification. Since the publication tools are
>> currently locked prior to the upcoming virtual meeting, I have published it
>> online here:
>> This represents a pretty significant refactoring of the specification,
>> hopefully to make the concepts and capabilities easier to understand. The
>> core protocol is largely the same as before, but there are a number of
>> serious updates:
>>  - Continuation requests happen at a URL returned in the TX response. The
>> “handle” is still sent as one of the input values here, since the handle
>> can also be used it other contexts.
>>  - Tokens now can include the resources they are issued for
>>  - Tokens can have an optional management URI for rotation and revocation.
>>  - “claims” has been removed in favor of “subject” dealing directly with
>> identifiers and assertions
>>  - the “user” request and response now align with identifiers and
>> assertions
>>  - Extensions and registries are more clearly enumerated throughout the
>> document
>>  - DID-related items have been excised in deference to a future possible
>> extension
>>  - Added a “pushback” mechanism to complement the “callback” mechanism
>>  - Simplified dynamic handle returns and access tokens based on developer
>> feedback (basically we dropped a bunch of “what if” stuff that nobody used
>> or liked, like SHA3 hashes for bearer tokens)
>> I’ve also updated the interactive examples on to
>> match this new draft. Hopefully it’s consistent with the draft text.
>> I have not yet, however, updated any of the implementations of XYZ to
>> take the elements of new syntax into account, so there might be some more
>> changes prior to the IETF meeting as I realize what terrible mistakes I’ve
>> made when doing that. :)
>> Feedback, as always, is welcomed, and thanks to everyone who’s provided
>> input to the project to date.
>>  — Justin
>> --
>> Txauth mailing list