[OAUTH-WG] Comments on draft-ietf-oauth-transaction-tokens-01

Joseph Salowey <joe@salowey.net> Thu, 11 April 2024 03:41 UTC

Return-Path: <joe@salowey.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CF6C14F6B5 for <oauth@ietfa.amsl.com>; Wed, 10 Apr 2024 20:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=salowey-net.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Uv81gec9Ur1 for <oauth@ietfa.amsl.com>; Wed, 10 Apr 2024 20:41:48 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFF9C14F60F for <oauth@ietf.org>; Wed, 10 Apr 2024 20:41:48 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2d8129797fcso99570491fa.1 for <oauth@ietf.org>; Wed, 10 Apr 2024 20:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20230601.gappssmtp.com; s=20230601; t=1712806906; x=1713411706; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=N92fysk+VNpmODDYx1VFy0NfcGV/fQyd9v3UXoWmvk4=; b=LVr1XPn3wRo6Is50a0nd/Rr3JoBWt5FAG9N6Xy7BlFHOv9EsUXmbbH/KvR8AVEB3lJ RCbOe3+Q4nZqyNr2TCSmTNdDNMq7VDC7vn79KS7MVsa+eR5aXBcz3I5vYIAQSaAMpGhh JuIFJXaA7Y9fDoExY6brAz7drmGMdPpyBuzaWiES6+J92yZIwEBpwKgVWJ3aOfapUwxE 0QUcHEiS6oaiHvzaT3nYKxKk+XClksQUhbzjfV43v9zndlnoa/b8HC1mh/RPbLUrh93D ESYFBC7p31EH+fmbbvpOWtScvpl1J0H7CvItvW8Out5Q8/uGo18EHTbyHCUKb4VIb6Ue BJPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712806906; x=1713411706; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=N92fysk+VNpmODDYx1VFy0NfcGV/fQyd9v3UXoWmvk4=; b=lf6JT08t1yLkkRsKYPSogif6XV67mXxA0JGPRU6gdQarpaG/XZkJ70ogWG/HZ0r8mR UUmauQToMQDvnyS+t7xTIjVUmS+0sOZLm259NGS7JcNde1bUzu9Dus2fqaM8i8bhbUyI adfnqPZ2PHG/Qt2Nx549Z+4DuPjXgfCI7pfoefQYzacBn7tnZSeagzkTxJOGJ//D/e6m zSnWL0zKXCSOAsSQwWKz857jG1SMH8YLIn5FvdaV3DI4qNrFXMd+No/I+Ea38h3W/6XR orF2arpJwITLNE5MWZvbUVVBzk6qTy36EFL/EKakdSEWRkcnG9CImiO92SJEqZa+Jss0 td6g==
X-Gm-Message-State: AOJu0YwSMt8XKSgtKaPC/wNXpMzRD73kVbeSyywFTz7n7WzSh4zc6QK2 d7a8XZKrleRBt++nrMALRTUtU/Ypdky9Tel1/FpoUmh7Pr6Z5/oZ+auTBly8fopa9s9dsnlChan 0rxigBgvryrIWUmtcuzKjj/HT2cm9/r+VjV9N5sAnHPG4RgIx
X-Google-Smtp-Source: AGHT+IFbnmiYFHS2IOtHDF7VCKDaJ4LlfmHMoykW4688FjDcZpSirsnni3pYKegDj1ALLxWvQANZEZcPSmtiIvrty9o=
X-Received: by 2002:a2e:98c7:0:b0:2d8:dd28:8748 with SMTP id s7-20020a2e98c7000000b002d8dd288748mr2090811ljj.1.1712806905484; Wed, 10 Apr 2024 20:41:45 -0700 (PDT)
MIME-Version: 1.0
From: Joseph Salowey <joe@salowey.net>
Date: Wed, 10 Apr 2024 20:41:33 -0700
Message-ID: <CAOgPGoB9M1ahVMw=B3AyrX2LUi5zby2iHfVArNw-V1peSgNe6g@mail.gmail.com>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002bb6c10615c9ef6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/TfG0BxKs5L1EVgL9LujQOFHmaII>
Subject: [OAUTH-WG] Comments on draft-ietf-oauth-transaction-tokens-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2024 03:41:49 -0000

I have reviewed the Transaction Token document.  In general I think it is a
needed document and I am glad there is work in this area. I have some
questions and comments below:

1. Section 4 defines Trust Domain and seems to point to RFC 7519.  I
couldn't find any reference to trust domain in 7519.

2. Why would you not include a kid claim? it seems that key rotation should
be supported. Is there harm in requiring a kid?

3. From the text, I don't really understand what the purp: claim is for.

4. One of the things I expected to see in some txn-tokens is a
username/email, but I did not see that in any examples, while there are
privacy considerations here, is there a reason why it is not included?
Would this be in the rctx: or the azd: claim? It not clear when I would use
azd or rctx for a particular data value.

5. As discussed on the list I think there may be cases where there will not
be an Oauth token to exchange.  THe decision is that this is out of scope
for this document, but the case should probably be mentioned.

6. Is it intended that a single transaction token service endpoint can
serve more than one trust domain? (it seems like the protocol supports, but
I am not sure if it is a design goal).

7. For a replacement token  7.4 it says the replacement may not change the
rctx, but does not say anything about the azd.   In section 5.2 it says
that azd: remains immutable during the call chain.  It seems that these two
things do not line up and the replacement token needs something to change.
 Perhaps azd is not immutable?  What are the asserted values that may
change referred to in 7.4.1.

8. Section 7.5 is referring to OAUTH client authentication? Should it refer
to RFC 8705 for mTLS/SPIFFE case?

9. Section 9.1 it probably should be mentioned earlier in the document that
a transaction token cannot be issued based on a refresh token.

Once again, thanks for your work on this document, I think it will be very
useful.

Joe