[OAUTH-WG] Review of draft-ietf-oauth-jwsreq-26.txt

Francis Pouatcha <fpo@adorsys.de> Sat, 01 August 2020 14:44 UTC

Return-Path: <fpo@adorsys.de>
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 29DDC3A0B32 for <oauth@ietfa.amsl.com>; Sat, 1 Aug 2020 07:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
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 IJXqDD2AyK5u for <oauth@ietfa.amsl.com>; Sat, 1 Aug 2020 07:44:53 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E899F3A0B2C for <oauth@ietf.org>; Sat, 1 Aug 2020 07:44:52 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id c80so10749342wme.0 for <oauth@ietf.org>; Sat, 01 Aug 2020 07:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to; bh=FNKMYGRUk74YAwWQYXghnFRyuSa4NzFF3d350XFZlfI=; b=hr1ZC4M4PE92yZ5VVgtQAk9UY5XtPtenQk0bWBFp4x5iG/L7mn8WBn4YuX2JKCor6h 7gqRDQAqe/NMU53/q2WFTfuhyMyICFU7HzLy86G2mYkeDwknogYt/622db4qdbFyuXFO kb3qOt0yTk83vF20OSlFFFFgJUhkMltKyVodA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FNKMYGRUk74YAwWQYXghnFRyuSa4NzFF3d350XFZlfI=; b=FQQaiJDJCggWbAUghy16LTVZfYJqFLSwztIb+vawqwKK9990YHbqHpzeC7hicl/2Fh 4jb9O0Km4/pM7ykOQJ0PASgRlJHkom8Awk2p97jx7SOWtgXJXou3BLZEiWiuSNdhu2NJ ot3micjwmYOf9SdEA9akXdVRdwMsBcvwPFBzMxBZ26YhH0E7+yynm0IXNLO3p9ac+5vZ AoB1ueUxkTMSRfbJjXNFZzuUBEK0Q9IHzAXI2TVawKN4yGa5gDlzAi6xA8Wm+kphaj54 InUZkAiRD8wFLFCE5PnBe3wxsYaUCrtGdTljtBq1++9otWfZrHAXRYb2o6OeGtOjXQIP YlZg==
X-Gm-Message-State: AOAM5311rvPuxChqA67mt4ZjRDhcsUJzxWrdZGwNqn8pS55DYWDr4uww wxWIUY3mMM1cWoUFLFB12CalP4KUgfMqe2gpdNryd4eR/Fs=
X-Google-Smtp-Source: ABdhPJz8jxLdDV93ThA/1jJ87nakkClEUKRqvfNaT4imHkHz4gp5YkEPEFOyWHkzbnTXtf65zw+RRM76JjsURYK7RpQ=
X-Received: by 2002:a7b:c3d4:: with SMTP id t20mr8221488wmj.8.1596293090890; Sat, 01 Aug 2020 07:44:50 -0700 (PDT)
MIME-Version: 1.0
From: Francis Pouatcha <fpo@adorsys.de>
Date: Sat, 01 Aug 2020 10:44:40 -0400
Message-ID: <CAOW4vyNscEbT4pO41fxp=Ma9ziVt=k_t1mO0uZrZnefbZ050eA@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a3eadb05abd1f238"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SGLkJXx6YCVGByLRpj6O2a0ztXM>
Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-26.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 01 Aug 2020 14:44:55 -0000

Below is my review of the draft-ietf-oauth-jwsreq-26.txt:

Section: 1. Introduction : Signed JWT also provides for non repudiation.

Under the section:
Using JWT [RFC7519] as the request encoding instead of query parameters has
several advantages:

Therefore I suggest adding this:
...
(e) (non repudiation) the signed JWT request can be archived by the AS as
is and used later in investigation and auditing processes.


Section: 10.5
Text block repeated twice"
<<When the value of it as a server metadata is "true", then the server
   MUST reject the authorization request from any client that does not
   conform to this specification.  It MUST also reject the request if
   the request object uses "alg":"none".  If omitted, the default value
   is "false".>>

Section: 12.1
Must a TFP validate every single authorization request to be sent by Client
to AS?

I thought:
- Certificate issued by TFP is proof that the client abides by trust
framework principles. Certificate can also contain details on resources
accessible to client (e.g. AIS, PIS)
- AS understands the content of the certificate and can use it to validate
adherence of client to TF. Removing the need to have to send each authz
request to the TFP for validation.


Best regards,

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/