[OAUTH-WG] JWT Secured Authorization Request: Inconsistencies with request_uri

Dave Tonge <dave.tonge@momentumft.co.uk> Fri, 24 March 2017 16:15 UTC

Return-Path: <dave.tonge@bluespeckfinancial.co.uk>
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 AC87E1270FC for <oauth@ietfa.amsl.com>; Fri, 24 Mar 2017 09:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
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 obYUSP3zDvGq for <oauth@ietfa.amsl.com>; Fri, 24 Mar 2017 09:15:27 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 448311296ED for <oauth@ietf.org>; Fri, 24 Mar 2017 09:15:26 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id y18so5528671itc.1 for <oauth@ietf.org>; Fri, 24 Mar 2017 09:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:from:date:message-id:subject:to; bh=voreSWZmCm28FoxpZWWAejI6sEHn0oQpj9vorjdprMM=; b=aTxWlss0Gc4r+puaYdb/70DiL4p09/4VwY0SxyS0qQbMaXN95B8hyVxh/WNAs7SdKP MGzx/E6vV2N8DixvhcG1Nt+9NM+YFBgzU0Mi/t2cUv251Yox8sYIlwcWRoT323+880f5 Jx8FxGwfTkAT/7gy9E0/dbJC3pK19tCmnedpg=
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=voreSWZmCm28FoxpZWWAejI6sEHn0oQpj9vorjdprMM=; b=XsAY6bPDzD16VBQjmStB0EZv48+j+ostAjnjczPQjYg2ZaTMEmg0arjtJKkxw3bpBY tCx8QcQhD62bPU2IRrPTuP96DmXTOasJeOfOia0lUk1FTsqSoJxnWpUzb2hEWI3LLhtp jtXkWEz26ncT22Tt4+4syWMPYAuirVKLMKeDjY4pUXkKue69z5lH6qfcS45NQPoZP+Wn R9vapbGUL/mOiCkd8gxlCD9YbhqgotelKqUgLVnIhFd6GtkmDk6QOzAKxICQOfgNhlfp 0AUIKntXopTgODZui52YPw59LjQ79tJMUNPQcy/8iWihtdJbQ3ZP2SCFhrgr6H/qYsmu /icw==
X-Gm-Message-State: AFeK/H1aT9ty4DV84NkILTwy4QGw+Zi3VbA2MoBudjrDSskkRYUqt8JSbtg5smuEQcYjjuIx/UxA0jXbZFtZaHfm
X-Received: by 10.107.55.68 with SMTP id e65mr9228359ioa.145.1490372126115; Fri, 24 Mar 2017 09:15:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.164.223 with HTTP; Fri, 24 Mar 2017 09:15:05 -0700 (PDT)
From: Dave Tonge <dave.tonge@momentumft.co.uk>
Date: Fri, 24 Mar 2017 16:15:05 +0000
Message-ID: <CAP-T6TSUm=-UQnp8XrjqUs71R7zHkO43ajuOFiJB20ovx_7Xkw@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a114ac87e292809054b7c4d04"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/cbiUriAyUFmLcCtLD4-GhyVbLpw>
Subject: [OAUTH-WG] JWT Secured Authorization Request: Inconsistencies with request_uri
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 24 Mar 2017 16:15:30 -0000

Hi Nat and John

I have some questions re the JWT Secured Authorization Request spec
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12

*1. Does the request_uri always have to be an URL? *
If the request object is hosted by the client then it makes sense, but if
10.3.d is followed and the AS provides an endpoint where the client can
exchange a request object for a "Request Object URI" then it would seem
acceptable for that uri to be an urn. Only the AS would need to be able to
fetch the request object and therefore there would be no need for the
request object to be made available via https.

*2. Should the mechanism described in 10.3.d be explained in 5.2?*
I think that 10.3.d could be widely used as it solves a number of problems
- however it is currently not clearly defined in either OIDC Core
or jwsreq.

*3. The spec seems inconsistent on the use of HTTPS*
Subject to any discussion re request_uris always being urls, there seems to
be an inconsistency between 5.2 and 5.2.1

5.2:

 The scheme used in the "request_uri" value *MUST be "https",
   unless* the target Request Object is signed in a way that is
   verifiable by the Authorization Server.


5.2.1

The Client stores the Request Object resource either locally or
   remotely at a URL the Authorization Server can access.  *The URL MUST
   be HTTPS URL*.  This URL is the Request Object URI, "request_uri".



Thanks

-- 
Dave Tonge
CT
O, Momentum Financial Technology