Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06

Brian Campbell <bcampbell@pingidentity.com> Fri, 06 November 2015 20:45 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CEA1B3081 for <oauth@ietfa.amsl.com>; Fri, 6 Nov 2015 12:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level:
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=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 pME926Xjoc1d for <oauth@ietfa.amsl.com>; Fri, 6 Nov 2015 12:45:49 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 910761B3080 for <oauth@ietf.org>; Fri, 6 Nov 2015 12:45:49 -0800 (PST)
Received: by igdg1 with SMTP id g1so46359743igd.1 for <oauth@ietf.org>; Fri, 06 Nov 2015 12:45:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QlCa6rq8nYazGMZu2Ha4x5o9WvfZoYpsb3ACCNRW9rA=; b=QUMBafTrVKpK7BHCFooRBmrIMeEJwYa/gL/ZQbhpydms9rN384UeOBtBylhqTcL9gq oZmdR40lOnS1PN13pDYSlxuwcm6b5BV82lJni/SdAm2RdUJBV04+vgEhrae+G4hIdCgO Ds2KLkEHqrhUoJjtzvoWsmUaRjP8NO8DaogG0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QlCa6rq8nYazGMZu2Ha4x5o9WvfZoYpsb3ACCNRW9rA=; b=iVmK/y5UZHkA5aWtCZTN9su4ZHnTuQ33WEPEUbyU3ljf18Pdc1qsm5cTV6IsrnI8M6 wsyzFIhfDXhWHEdTp6QmyCrYghPQMToMW+Xnq2n54exSWAH7pnXqYHAGVLi0eraC/RWV cYf08zCsVFaCzkT2u+O4SACUrzH85wVDloftM4wgaCmq+S4vTd1XCJMq6jNe8xb34Z6f /aPj7yRSxCjk706pBKRtPHJmqGDOybSO6jrcb0kL/NCwxl47arUpNICHg6FB0SFIrJ1E KapYfO3CQS6GwkYkJXbveYrTdrKwXWOu7uF5qSfnbPzPCb10hqes+xuYCEVIlK4QgW3B h7yw==
X-Gm-Message-State: ALoCoQkzIPZJgB7Dr3gAyvwaKisHHMg9QChm3UIoD+vaW/bcStt8FzDK9AQaEOt8sKAZMGuRkWkq
X-Received: by 10.50.28.70 with SMTP id z6mr2133992igg.57.1446842748816; Fri, 06 Nov 2015 12:45:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.117.132 with HTTP; Fri, 6 Nov 2015 12:45:19 -0800 (PST)
In-Reply-To: <BY2PR03MB4422A5C4671F0DB1F312919F5210@BY2PR03MB442.namprd03.prod.outlook.com>
References: <CA+k3eCRH1APvnrC6sxru88MvzNmqULe-42r4+1mex-08DXhGjw@mail.gmail.com> <152AD4F1-84EF-47DC-9A41-C7413DE5464B@mit.edu> <BY2PR03MB4422A5C4671F0DB1F312919F5210@BY2PR03MB442.namprd03.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 6 Nov 2015 13:45:19 -0700
Message-ID: <CA+k3eCRoq6vN0nPLZ4APfPFyJirjeP3HFo2XrFMk0ZviB0fH4Q@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=089e0158b2ce16fc070523e5545e
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Ote2mRKjv8rUm0xCNL8rTMscbK0>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Nov 2015 20:45:53 -0000

Apologies - I'd forgotten about the pending errata.

On Wed, Oct 28, 2015 at 5:07 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> This working draft
> http://openid.net/specs/openid-connect-registration-1_0-29.html
> containing the OpenID Connect Dynamic Registration errata 2 edits to date
> contains the registration requests that you’re referring to.  See
> http://openid.net/specs/openid-connect-registration-1_0-29.html#DynRegContents
> and
> http://openid.net/specs/openid-connect-registration-1_0-29.html#TEAMContents
> .
>
>
>
>                                                             -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Justin Richer
> *Sent:* Wednesday, October 28, 2015 3:16 PM
> *To:* Brian Campbell
> *Cc:* <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06
>
>
>
> The errata/update version of Connect’s registration spec need to register
> a bunch of stuff in the Dyn-Reg IANA registry, but I don’t think that’s
> been done yet.
>
>
>
>  — Justin
>
>
>
> On Oct 27, 2015, at 3:41 PM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
>
>
> Sakimura-san, Senior Bradley, and distinguished members of the OAUTH WG,
>
> I re-read draft-ietf-oauth-jwsreq (-06 anyway, it'd been a while) for WGLC
> and, while I feel it's in pretty good shape, I did have a few comments on
> the draft. Those are listed below in roughly the order I came across things
> while reading the document.
>
>
> To my eye, "oauth-jar" looks a bit awkward. I'd suggest changing the
> abbrev to something like
> "OAuth JAR".
>
> From the wording in Section 3
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-3>, it is
> unclear whether the Request Object can be a JWE only or if a JWS is always
> used (with alg:none for unsigned) and is nested within a JWE when
> encryption but not singing is needed. To my reading there is text that
> suggest both cases. Which is it? I think some clarification is needed
> around this. Section 5.1
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-5.1>
> doesn't help me as I'm unsure if "unsigned (plaintext) Request Object" is
> an out-of-date usage of the old way to refer to the "none" JWS alg or is
> intended to mean the straight up JSON of the request object parameters.
>
> Also in Section 3
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-3>, the
> sentence 'The Authorization Request Object MAY alternatively be sent by
> reference using the "request_uri" parameter.' reads a little awkward
> because the other alternative isn't explicit discussed anywhere nearby.
> Perhaps something like "The Authorization Request Object may be sent by
> value as described in section 4.1 or by reference as described in section
> 4.2."?
>
> Also in Section 3
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-3>, the
> sentence "If a required parameter is not present in neither the query
> parameter nor the Request Object, it forms a malformed request." made my
> brain hurt. Maybe reword to something like, "If a required parameter is
> missing from both the query parameters and the Request Object, the request
> is considered malformed."?
>
>
> Also in Section 3
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-3>, '...
> the Authorization Request Object SHOULD contain the Claims "iss" (issuer)
> and "aud" (audience) as members ...', however, that will produce a
> parameter name conflict with the "aud" parameter from OAuth 2.0
> Proof-of-Possession: Authorization Server to Client Key Distribution.
> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02>
> Seems like draft-ietf-oauth-pop-key-distribution will need to change its
> parameter name (aud in JWT is pretty well established). And shouldn't
> draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim Names
> <http://tools.ietf.org/html/rfc7519#section-4.1> (at least iss and aud
> but maybe exp and others) as authorization request OAuth parameters
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters>
> ?
>
> Also in Section 3
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-3>, I
> personally feel like the "extension variables" detract from the example
> being able to easily convey the concept. I would suggest using only
> 'vanilla' OAuth parameters. Or, at the very least, removing the "claims"
> stuff, which doubles the space used by the example and is a very OpenID
> Connect specific thing. This applies to the examples throughout the draft
> including those that have the encoded JWT Request Object.
>
> In Section 4
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-4>, the
> whole "The client constructs the authorization request URI by ..." followed
> by the list of parameters is somewhat awkward to me - especially with the
> "REQUIRED"s. Why list "state" here and none of the others here? I think I
> know why (you expect state to vary on each request but not others) but a
> lot of inferring needs to happen from the reader.  For the extension
> defined in this document, one uses either request_uri or request (but not
> both, right? I'm not sure it's explicitly stated anywhere) and whatever
> other parameters are needed in the given situation. Maybe just some text
> towards that end rather than the list format?
>
> Also in Section 4
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-4>, the
> request_uri in the example is a lot like the URI that's used for
> redirect_uri in a lot of places (the /cb path, I think, was intended to
> short for callback). I mean, it *could* happen but the example is more
> confusing than needs to be. It's also too long/wide for the page - add some
> line breaks, which are for display purposes only. Perhaps move this example
> to 4.2(.1) somewhere and match the value with the value shown there?
>
> Also in Section 4
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-4>, the
> sentence that starts with 'When the "request" parameter is used...'
> suggests that the text about JWT parameters superseding others is only
> applicable to the pass by value method but it applies to both. Perhaps
> change '"request" parameter' to 'Request Object'?
>
> The second paragraph of Section 4.2.1
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-4.2.1>
> talks about "requested values for Claims" which is an OpenID Connect thing
> that isn't really applicable to this draft. Can this paragraph be dropped
> or made more general to be about any potentially sensitive or PII data?
>
> Also in Section 4.2.1
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-4.2.1>,
> is "... at a URL the Server can access... " - assume the "Authorization
> Sever"?
>
> Isn't it a bit odd in Section 5.2
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-5.2> to
> talk about the "request_object_signing_alg" which is defined in OpenID
> Connect Dynamic Client Registration
> <http://openid.net/specs/openid-connect-registration-1_0.html> (which is
> not referenced) and kinda mentioned in OpenID Connect Core
> <http://openid.net/specs/openid-connect-core-1_0.html> (informative
> referenced)? I don't know that it belongs here? Or if it does, what about
> request_object_encryption_alg and request_object_encryption_enc? I suppose
> related to that is the question of if/how to use the client_secret for HMAC
> and symmetric encryption algorithms and if that needs to be discussed here?
> Indicating public key(s) too for that matter. Seems like all the
> metadata/registration stuff should be in here. Or it should all be out of
> scope. But just the request_object_signing_alg seems odd to me.
>
> Section 6
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-6> says
> that "... this document defines additional error values ..." but those were
> previously defined in 3.1.2.6 of OpenID Connect Core
> <http://openid.net/specs/openid-connect-core-1_0.html#AuthError>. Maybe
> just change the wording to reflect the real state of things?
>
>
>
> Section 7
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-7> says
> that "The request_object_signing_alg OAuth Dynamic Client Registration
> Metadata is pending registration by OpenID Connect Dynamic Registration
> specification." But is that true? The registry
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata>
> doesn't have it and Connect's Registration
> <http://openid.net/specs/openid-connect-registration-1_0.html#IANA>
> "makes no requests of IANA".
>
> As I'm sure reading this has been a ton of fun for the editors, I'm sure
> you will be happy to please add me to the Acknowledgements Section
> <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-06#section-9> ;)
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>