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

Justin Richer <> Wed, 28 October 2015 22:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 99F2B1AD272 for <>; Wed, 28 Oct 2015 15:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TkByfJ8B9_O3 for <>; Wed, 28 Oct 2015 15:16:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BEE4C1AD291 for <>; Wed, 28 Oct 2015 15:16:34 -0700 (PDT)
X-AuditID: 12074422-f79976d0000078ca-97-56314941d837
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id CF.ED.30922.14941365; Wed, 28 Oct 2015 18:16:33 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t9SMGWYC013423; Wed, 28 Oct 2015 18:16:32 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t9SMGSkX005877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2015 18:16:30 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_7781E788-D0BD-461B-8A30-96571FF7D2BD"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <>
In-Reply-To: <>
Date: Wed, 28 Oct 2015 15:16:27 -0700
Message-Id: <>
References: <>
To: Brian Campbell <>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixG6nouvoaRhmsGaLlMXq/zcZLXbdPsJo cfLtKzaL1Xf/sjmweCxZ8pPJY8mv84wed49eZPG4fXsjSwBLFJdNSmpOZllqkb5dAlfGg9+/ 2Av+zWKs6H/8mL2BcW8LYxcjJ4eEgInEjysbmCFsMYkL99azdTFycQgJLGaS2LShkRUkISSw kVHi8iMZiMR+Jol3q+axgCSYBRIk7m9uBbN5BfQkXt26DNYgLOAh8eP1P7A4m4CqxPQ1LUwg NqdAoMSJJzvZQWwWoPjSZ9tZIeaUSizq2MoMMcdK4kX/daBeDqBlARJT+0JAwiIC+hK3n85h hzhUVmL370dMExgFZiG5YhaSKyDi2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd 3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2M4NhwUdrB+POg0iFGAQ5GJR5eDwPDMCHWxLLi ytxDjJIcTEqivAXuQCG+pPyUyozE4oz4otKc1OJDjBIczEoivNIsQDnelMTKqtSifJiUNAeL kjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQne+SBDBYtS01Mr0jJzShDSTBycIMN5gIZ7eYAM Ly5IzC3OTIfIn2JUlBLnfQTSLACSyCjNg+sFpS4HdyGbV4ziQK8I8x4AqeIBpj247ldAg5mA Brtf0QUZXJKIkJJqYKy9LPjGJZdz2fQW6ekKGV0H+pNt/MyuHiyb5bd6hUL02U4xU5sSdYVG 4bBTO0+ZiZRMmHpv36q4mmzn4xOvc6w4dPDd0eIt9p7G6a9NykOW7mNbnCyZKPZR8Z2OfnPV NZE/D+tUTC5eb//gvM6CIV4v+6PGYgNRzUf/l6xUZi+d8u/elCkV7kosxRmJhlrMRcWJAAYy Lt44AwAA
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2015 22:16:38 -0000

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 <> 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 <>, 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 <> 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 <>, 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 <>, 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 <>, '... 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. <> 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 <> (at least iss and aud but maybe exp and others) as authorization request OAuth parameters <>?
> Also in 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 <>, 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 <>, 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 <>, 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 <> 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 <>, is "... at a URL the Server can access... " - assume the "Authorization Sever"? 
> Isn't it a bit odd in Section 5.2 <> to talk about the "request_object_signing_alg" which is defined in OpenID Connect Dynamic Client Registration <> (which is not referenced) and kinda mentioned in OpenID Connect Core <> (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 <> says that "... this document defines additional error values ..." but those were previously defined in of OpenID Connect Core <>. Maybe just change the wording to reflect the real state of things?   
> 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 <> doesn't have it and Connect's Registration <> "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 <> ;) 
> _______________________________________________
> OAuth mailing list