[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