Re: [Txauth] New version of XYZ Draft

Justin Richer <jricher@mit.edu> Fri, 17 July 2020 21:36 UTC

Return-Path: <jricher@mit.edu>
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 5EC0B3A07EE for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 14:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.081
X-Spam-Level:
X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, 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=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 6SResr45nXCH for <txauth@ietfa.amsl.com>; Fri, 17 Jul 2020 14:36:48 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539F93A07E3 for <txauth@ietf.org>; Fri, 17 Jul 2020 14:36:48 -0700 (PDT)
Received: from [192.168.1.3] (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 06HLaF5C020730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jul 2020 17:36:46 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDA524C4-98FB-4D7E-AB06-0BE02C32822D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 17 Jul 2020 17:34:10 -0400
In-Reply-To: <CAD9ie-vm1roOtco_ZXr4DGxCSif9oFAZ7pKCvhHRHv=G_=u9uA@mail.gmail.com>
Cc: txauth@ietf.org
To: Dick Hardt <dick.hardt@gmail.com>
References: <A5C2F2EE-277B-4DE5-8839-C804CCD64A59@mit.edu> <CAD9ie-vm1roOtco_ZXr4DGxCSif9oFAZ7pKCvhHRHv=G_=u9uA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/k0YE6Xg4DX0WFiFRo-GUMDFg_Kg>
Subject: Re: [Txauth] New version of XYZ Draft
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2020 21:36:50 -0000

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 <dick.hardt@gmail.com> 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 <jricher@mit.edu <mailto:jricher@mit.edu>> 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:
> 
> https://oauth.xyz/draft-richer-transactional-authz <https://oauth.xyz/draft-richer-transactional-authz>
> 
> 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 https://oauth.xyz/ <https://oauth.xyz/> 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
> Txauth@ietf.org <mailto:Txauth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>