[Txauth] Comments on new version of XYZ Draft (draft-richer-transactional-authz-09)

Denis <denis.ietf@free.fr> Mon, 20 July 2020 09:33 UTC

Return-Path: <denis.ietf@free.fr>
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 A9B053A077A for <txauth@ietfa.amsl.com>; Mon, 20 Jul 2020 02:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.37
X-Spam-Level:
X-Spam-Status: No, score=0.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, PDS_OTHER_BAD_TLD=1.999, 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 iqSFjGBS-CXn for <txauth@ietfa.amsl.com>; Mon, 20 Jul 2020 02:33:32 -0700 (PDT)
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 696C43A0772 for <txauth@ietf.org>; Mon, 20 Jul 2020 02:33:31 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d52 with ME id 5MZV2300A2bcEcA03MZVRr; Mon, 20 Jul 2020 11:33:29 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 20 Jul 2020 11:33:29 +0200
X-ME-IP: 90.79.51.120
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf.org
References: <A5C2F2EE-277B-4DE5-8839-C804CCD64A59@mit.edu> <CAD9ie-vm1roOtco_ZXr4DGxCSif9oFAZ7pKCvhHRHv=G_=u9uA@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <8e09c6e9-5396-dba8-850f-cdf1d602431d@free.fr>
Date: Mon, 20 Jul 2020 11:33:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CAD9ie-vm1roOtco_ZXr4DGxCSif9oFAZ7pKCvhHRHv=G_=u9uA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A924BC1E9065F524BA19731C"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/F1j0l7v6ZoCgaxFkOSQWy9Cs2a0>
Subject: [Txauth] Comments on new version of XYZ Draft (draft-richer-transactional-authz-09)
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: Mon, 20 Jul 2020 09:33:35 -0000

Hi Justin,

Since you mentioned "Feedback, as always, is welcomed", hereafter are a 
few comments:

1) The trust relationships are not described: Example : A trusts B for 
some behaviour C.

2) There is no figure to illustrate the various exchanges and to 
indicate whether they are mandatory or optional.

3) The user consent is not addressed.

4) The draft states:

9 Discovery

            By design, the protocol minimizes the need for any 
pre-flight discovery. To begin a transaction, the RC only needs to know
            the transaction endpoint of the AS, and everything else can 
be negotiated dynamically.

If the RC wants to optimize its calls to the AS, it MAY send an HTTP 
OPTIONS request to the transaction endpoint to retrieve
            the server's discovery information.

At the beginning, the client has to clue about what will be requested by 
the RS. Furthermore what will be requested by the RS
will be dependent upon the operation that will be attempted at the RS 
and /the requested information may change at any point of time/.

As long as the client does not know which attributes from which AS(*s*) 
will be needed to perform a given operation on a RS,
the client may not know which AS(*s*) to contact. So the client shall, 
at least once, contact the RS.

Another point is about the RS discovery information. Some RSs, may only 
be willing to disclose some parts of their discovery information
to authenticated users/client applications and some other parts of their 
discovery information to users or client applications that have
already successfully performed some operation(s). The disclosed 
discovery information usually depends both upon the operation that is 
requested
and upon which operation(s) has/have already been successfully 
performed. The case where the discovery information is static and publicly
disclosed should be considered as a specific case of the general case.


5) A Client is not requesting one or more access tokens for itself, but 
on behalf of a user or a client application. Users and client applications
may have an account on the AS, but not Clients. A Client is trusted by 
its user or by its client application to interface with ASs and RSs.

At this time, there is no trust relationship between a Client and an AS 
... unless there is a desire to consider the use of secure elements
by users.


6) The model seems to be limited to the case where RSs have a 
relationship with one and only one AS (i.e. it is a mono-domain 
environment)
and seems to be not applicable nor scalable over the Internet with 
millions of RSs trusting thousands of ASs.

Section 2.1.2 called "Requesting Multiple Access Tokens" provides an 
example for two access tokens. However, it is not explained how
such mechanism would be able to obtain multiple access tokens from more 
than a single AS.


7) "By design", the protocol mandates to tell to the AS which RS will be 
accessed and which operations will be attempted.

This places the AS in an perfect position to act as Big Brother: the AS 
will be able to trace which operations are likely to be performed by
either a user or a client application, on which RS and at which instant 
of time. In addition, if artificial intelligence (AI) is used by the AS or
by a third party to which this information is communicated, this leaves 
the gate wide opened to a lot of undisclosed usages "behind the scenery".

Since it is not possible to be confident that ASs will never perform 
some additional tasks "behind the scenery", there is the need to prevent 
ASs
to behave in an inappropriate manner. Unfortunately, the proposed 
architecture is unable to provide this property.

8) Section 14 (Privacy considerations) mentions:

TBD: There are a lot of privacy considerations to add.

Indeed, in particular, readers should be warned that this protocol 
allows the AS to trace/log which operations are likely to be performed
by every user or client application, on which RS, and at which instant 
of time.

Denis

> 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
>
> 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/ 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