>From the discussions I have had, I agree with Nat's assment.
John B.
On 1/31/2020 12:06 AM, Nat Sakimura wrote:
> Hi
>
> Re: JWT
> I understand your concern and we can put some explanatory notes. Having
> said that, JAR is still a valid JWT, I think :-)
>
> Re: client_id
> We actually discussed client_id issues with OpenID Connect WG Call
> yesterday as well.
> I hear a pretty strong voice from the developer community that they want
> client_id as a query parameter and it should not pose a security issue as
> long as it is required to match what is in the JWT. In fact, that was the
> position taken in the WG last call. So, in effect, WG is actually pushing
> back the change IESG wanted.
>
> As I understand it, there are two points to be made:
> (1) If client_id is not in the query parameter, then it MUST be in the JWT
> header OR MUST be supplied as a query parameter in some encrypted JAR case
> (2) To check if requst_uri is a registered and valid URI, not having
> client_id in the query parameter will have performance impacts in a large
> AS.
>
> The encryption case (1) can be solved by adding client_id in the JWT Header
> but it will not solve (2).
> So, IMHO, putting client_id back to the query parameter (and MUST match the
> value in JWT) is a way to go.
> Since that was the position by the WG at the WG Last Call, I do not feel
> that it needs to be brought back to the WG last call,
> but that is your call.
>
> Best,
>
> Nat Sakimura
>
> On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk <ka...@mit.edu> wrote:
>
>> Hi Nat,
>>
>> Now it is my turn to apologize for taking a long time.
>>
>> I think I see the general direction these changes are going in, and it's a
>> reasonable approach to the unfortunate situation we find ourselves in with
>> respect to JWT claims vs. OAuth parameters. In effect, what we're doing is
>> making a "profile" (for lack of a better term) of JWT, that leverages the
>> mechanisms and algorithms of JWT but uses a different registry for
>> interpreting the claims in the token (that is, OAuth Parameters vs. JWT
>> Claims). We can tell that this "profile" of JWT is being used because of
>> the context in which the JWT is transferred/received: if it's the "request"
>> parameter, that's part of the definition of the OAuth Parameter, and if
>> it's the result of dereferencing a "request_uri", the
>> application/oauth.authz.req+jwt media-type clearly indicates how the
>> contents should be interpreted.
>>
>> However, the changes in the -20 do not give the reader much of any hint as
>> to this being what's expected to happen, and that stock RFC 7519 JWT is
>> *not* what's in use. So I'd request that we take a close look at how the
>> document uses "JWT" vs. "JWT encoding" (etc.); add an explicit statement
>> that while the JWT encoding is in use, the contents are to be interpreted
>> by interpreting the JWT claims as OAuth Parameters (and not as per the IANA
>> registry of JWT claims); and add some discussion (similar to the above)
>> about how the application context makes it unambiguous whether the
>> JWT-encoded claims are standard JWT claims or OAuth Parmaters as per this
>> document.
>>
>> With respect to my second ("discuss discuss") point, Nat and I did have a
>> discussion in-person and I accept that there may be some scenarios in which
>> skipping the authorization dialogue is appropriate, so the example can
>> remain.
>>
>>
>> Moving on from my Discuss position, I do get the sense from the ongoing
>> discussion on the list that there's not clear agreement about the current
>> formulation that requires all parameters (but "request" and "request_uri")
>> to be in the JAR, especially with respect to "client_id" that might be
>> needed to unpack the JAR in some cases! So I'm not sure whether the WG
>> wants to bring the document back to the WG to iron out those issues before
>> it returns to the IESG. I'm a little reluctant to switch my position to
>> "No Objection" until we have a clearer picture of what the WG wants to do
>> on this front -- in my understanding, we can't really publish the document
>> without at least some solution ("client_id") for the encrypted-request
>> key-lookup case.
>>
>> Thanks,
>>
>> Ben
>>
>>
>> On Sun, Oct 27, 2019 at 10:12:50AM +0100, Nat Sakimura wrote:
>>> Hi
>>>
>>> Took a long time but finally all the changes needed to resolve the
>> DISCUSS
>>> comments are (hopefully) applied as -20.
>>>
>>> There is one change that impacts the process: the draft now has IANA
>>> request so it needs to be referred back to IANA.
>>>
>>> The IETF datatracker status page for this draft is:
>>> datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>
>>> Best,
>>>
>>> Nat Sakimura
>>>
>>> 2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker <nore...@ietf.org>:
>>>
>>>> Benjamin Kaduk has entered the following ballot position for
>>>> draft-ietf-oauth-jwsreq-19: Discuss
>>>>
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>>
>>>>
>>>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>
>>>>
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>>
>>>> This is a "discuss discuss" -- it's an important question and I'd like
>>>> to talk about it, but it's not clear that any change to the document
>>>> will be needed.
>>>>
>>>> Once this (and some of the more substantive items in the Comment
>>>> section) is resolved, I'd be happy to ballot Yes.
>>>>
>>>> The introduction notes as an advantage of JWT that:
>>>>
>>>> (d) (collection minimization) The request can be signed by a third
>>>> party attesting that the authorization request is compliant
>> with
>>>> a certain policy. For example, a request can be pre-examined
>> by
>>>> a third party that all the personal data requested is strictly
>>>> necessary to perform the process that the end-user asked for,
>>>> and statically signed by that third party. The authorization
>>>> server then examines the signature and shows the conformance
>>>> status to the end-user, who would have some assurance as to the
>>>> legitimacy of the request when authorizing it. In some cases,
>>>> it may even be desirable to skip the authorization dialogue
>>>> under such circumstances.
>>>>
>>>> I'm pretty uncomfortable about suggesting that the authorization
>>>> dialogue can/should be skipped; do we need to keep this example?
>>>> Maybe just talking about what an expected use case could be would
>>>> help alleviate my unease.
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Section 1
>>>>
>>>> While it is easy to implement, the encoding in the URI does not
>> allow
>>>> application layer security with confidentiality and integrity
>>>> protection to be used. While TLS is used to offer communication
>>>>
>>>> nit: this wording is a little hard to read; it might be easier to
>>>> reorder to "does not allow application layer security to be used to
>>>> provide confidentiality and integrity protection".
>>>>
>>>> The use of application layer security allows requests to be prepared
>>>> by a third party so that a client application cannot request more
>>>> permissions than previously agreed. This offers an additional
>> degree
>>>> of privacy protection.
>>>>
>>>> (side note) what would an example of such a third party be. (We
>> already
>>>> have the resource owner, the client, and the authorization server ...
>>>> maybe it's a fourth party?)
>>>>
>>>> Furthermore, the request by reference allows the reduction of over-
>>>> the-wire overhead.
>>>>
>>>> We only barely mentioned by-reference at this point (one line in the
>>>> Abstract), so I'd suggest "passing the request by reference".
>>>>
>>>> (4) its development status that it is an RFC and so is its
>>>> associated signing and encryption methods as [RFC7515] and
>>>> [RFC7516]
>>>>
>>>> nit: I'd suggest "its development status as a Proposed Standard, along
>>>> with the associated signing and encryption methods [RFC7515]
>> [RFC7516]."
>>>> (c) (confidentiality protection) The request can be encrypted so
>>>> that end-to-end confidentiality can be provided even if the TLS
>>>> connection is terminated at one point or another.
>>>>
>>>> nit: TLS is always terminated at or before the user-agent, though. So
>>>> maybe the user agent needs to get called out here as well (there could
>>>> of course be TLS termination earlier than the user-agent in some cases,
>>>> too).
>>>>
>>>> 2. When the client does not want to do the crypto. The
>>>> Authorization Server may provide an endpoint to accept the
>>>> Authorization Request through direct communication with the
>>>> Client so that the Client is authenticated and the channel is
>> TLS
>>>> protected.
>>>>
>>>> How can you "not want to do [the] crypto" but still be doing TLS (with
>>>> crypto)? Perhaps we're looking for "not want to pay the additional
>>>> overhead of JWS/JWE cryptography on top of TLS"?
>>>>
>>>> Section 1.1
>>>>
>>>> RFC 8174 has updated BCP 14 boilerplate text to use.
>>>>
>>>> Section 3
>>>>
>>>> nit: should this section be 2.3 to get wrapped into "terminology"?
>>>>
>>>> It might also be worth putting references in for the terms, though they
>>>> are largely common knowledge at this point.
>>>>
>>>> Section 4
>>>>
>>>> A Request Object (Section 2.1) is used to provide authorization
>>>> request parameters for an OAuth 2.0 authorization request. It MUST
>>>> contains all the OAuth 2.0 [RFC6749] authorization request
>> parameters
>>>> including extension parameters. The parameters are represented as
>>>>
>>>> nit: "all the parameters" kind of sounds like "all that are defined".
>>>> But I think the intent here is "any parameter used to process the
>>>> request must come from the request object and URL query parameters are
>>>> ignored", so maybe "MUST contain all the parameters (including
>> extension
>>>> parameters) used to process the OAuth 2.0 [RFC6749] authorization
>>>> request; parameters from other sources MUST NOT be used", akin to what
>>>> we say down in Sections 5 and 6.3.
>>>> But we need to be careful about the wording to not exclude the usage of
>>>> the "request" and "request_uri" query parameters to find the Request
>>>> Object!
>>>>
>>>> the JWT claims. Parameter names and string values MUST be included
>>>>
>>>> nit: maybe "the JWT claims of the object"?
>>>>
>>>> any extension parameters. This JSON [RFC7159] constitutes the JWT
>>>> Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then
>>>> signed or signed and encrypted.
>>>>
>>>> nit: I think we want "This JSON [RFC7159] object".
>>>>
>>>> (Long quote incoming)
>>>>
>>>> The following is an example of the Claims in a Request Object before
>>>> base64url encoding and signing. Note that it includes extension
>>>> variables such as "nonce" and "max_age".
>>>>
>>>> {
>>>> "iss": "s6BhdRkqt3",
>>>> "aud": "https://server.example.com";,
>>>> "response_type": "code id_token",
>>>> "client_id": "s6BhdRkqt3",
>>>> "redirect_uri": "https://client.example.org/cb";,
>>>> "scope": "openid",
>>>> "state": "af0ifjsldkj",
>>>> "nonce": "n-0S6_WzA2Mj",
>>>> "max_age": 86400
>>>> }
>>>>
>>>> Signing it with the "RS256" algorithm results in this Request Object
>>>> value (with line wraps within values for display purposes only):
>>>>
>>>> eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
>>>> F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
>>>> c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
>>>> JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
>>>> bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
>>>> Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
>>>> ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
>>>> ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
>>>> Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
>>>> wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
>>>> ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
>>>> sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
>>>> dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
>>>> luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
>>>> F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
>>>> KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
>>>> 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
>>>> ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
>>>> iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
>>>>
>>>> Decoding the base64 of the body, we see:
>>>> {
>>>> "iss": "s6BhdRkqt3",
>>>> "aud": "https://server.example.com";,
>>>> "response_type": "code id_token",
>>>> "client_id": "s6BhdRkqt3",
>>>> "redirect_uri": "https://client.example.org/cb";,
>>>> "scope": "openid",
>>>> "state": "af0ifjsldkj",
>>>> "nonce": "n-0S6_WzA2Mj",
>>>> "max_age": 86400,
>>>> "claims":
>>>> {
>>>> "userinfo":
>>>> {
>>>> "given_name": {"essential": true},
>>>> "nickname": null,
>>>> "email": {"essential": true},
>>>> "email_verified": {"essential": true},
>>>> "picture": null
>>>> },
>>>> "id_token":
>>>> {
>>>> "gender": null,
>>>> "birthdate": {"essential": true},
>>>> "acr": {"values": ["urn:mace:incommon:iap:silver"]}
>>>> }
>>>> }
>>>> }
>>>>
>>>> I'm not sure where the "claims" claim is coming from -- 6749 doesn't
>>>> seem to talk about it. (Note that this example is used later on as
>>>> well.)
>>>>
>>>> Section 5.2.1
>>>>
>>>> It is possible for the Request Object to include values that are to
>>>> be revealed only to the Authorization Server. As such, the
>>>> "request_uri" MUST have appropriate entropy for its lifetime. For
>>>> the guidance, refer to 5.1.4.2.2 of [RFC6819]. It is RECOMMENDED
>>>> that it be removed after a reasonable timeout unless access control
>>>> measures are taken.
>>>>
>>>> It sounds like a link to https://www.w3.org/TR/capability-urls/ might
>>>> also be useful.
>>>>
>>>> Section 5.2.2
>>>>
>>>> Do we want to remind the reader that the other query parameters are
>> just
>>>> for backwards compatibility?
>>>>
>>>> Section 5.2.3
>>>>
>>>> The following is an example of this fetch process:
>>>>
>>>> GET /request.jwt HTTP/1.1
>>>> Host: tfp.example.org
>>>>
>>>> It's useful to show good hygeine in examples; can we get the extra
>>>> entropy in this request that we have in the previous example(s)?
>>>>
>>>> Section 6.2
>>>>
>>>> The Authorization Server MUST perform the signature validation of
>> the
>>>> JSON Web Signature [RFC7515] signed request object. For this, the
>>>> "alg" Header Parameter in its JOSE Header MUST match the value of
>> the
>>>> pre-registered algorithm. The signature MUST be validated against
>>>> the appropriate key for that "client_id" and algorithm.
>>>>
>>>> Does "the pre-registered algorithm" concept exist in the specs outside
>>>> of draft-ietf-oauth-jwt-bcp?
>>>>
>>>> Section 9
>>>>
>>>> The error codes we list in Section 7 are already registered, for the
>>>> OIDC usage. Do we want to say anything about that? (I guess it would
>>>> be disallowed by process to try to update the existing registration to
>>>> also point at this document.)
>>>>
>>>> Section 10
>>>>
>>>> We probably also want to reference draft-ietf-oauth-jwt-bcp.
>>>>
>>>> Section 10.1
>>>>
>>>> When sending the authorization request object through "request"
>>>> parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>>>> using JWE [RFC7516] with then considered appropriate algorithm.
>>>>
>>>> Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
>>>> similarly, in Section 4 we reiterate "signed then encrypted". Why is
>> it
>>>> okay to talk about just "signed or encrypted" here?
>>>>
>>>> Section 10.2
>>>>
>>>> (b) Verifying that the symmetric key for the JWE encryption is the
>>>> correct one if the JWE is using symmetric encryption.
>>>>
>>>> Similarly to the previous point, you also need to check the signature,
>>>> which will always be there.
>>>>
>>>> (d) Authorization Server is providing an endpoint that provides a
>>>> Request Object URI in exchange for a Request Object. In this
>>>>
>>>> I don't think this is a complete sentence (and it's definitely not a
>>>> parallel construction with (a)-(c)!). I think perhaps a crisp one-line
>>>> summary of this method would be "Delegating the authorization check to
>> a
>>>> separate "Request Object to Request Object URI" endpoint on the
>>>> Authorization Server". (The writing in the rest of this paragraph
>> could
>>>> also use an editing pass.)
>>>>
>>>> (e) A third party, such as a Trust Framework Provider, provides an
>>>> endpoint that provides a Request Object URI in exchange for a
>>>> Request Object. The same requirements as (b) above apply. In
>>>> addition, the Authorization Server MUST know out-of-band that
>>>> the Client utilizes the Trust Framework Operator.
>>>>
>>>> The Authorization Server also has to trust the third-party provider to
>>>> actually do its job and not misbehave, right?
>>>>
>>>> Section 10.3
>>>>
>>>> I'm not entirely sure what "[t]he endpoints ithat come into question in
>>>> this specification" is supposed to mean -- is it just "the OAuth 2.0
>>>> endpoints presently defined in Standards-Track RFCs"?
>>>>
>>>> In [RFC6749], while Redirection URI is included, others are not
>>>> included in the Authorization Request. As the result, the same
>>>> applies to Authorization Request Object.
>>>>
>>>> nit: included in what?
>>>>
>>>> Section 10.4
>>>>
>>>> It's probably also worth citing the generic URI security considerations
>>>> from RFC 3986, here.
>>>>
>>>> Section 10.4.1
>>>>
>>>> "request_uri", and (d) do not perform recursive GET on the
>>>> "request_uri".
>>>>
>>>> nit: remove the "do" in order to make the construction parallel.
>>>>
>>>> Section 12.1
>>>>
>>>> It is often hard for the user to find out if the personal data asked
>>>> for is strictly necessary. A Trust Framework Provider can help the
>>>> user by examining the Client request and comparing to the proposed
>>>> processing by the Client and certifying the request. After the
>>>> certification, the Client, when making an Authorization Request, can
>>>> submit Authorization Request to the Trust Framework Provider to
>>>> obtain the Request Object URI.
>>>>
>>>> side note: In my head the act of certification was the act of making
>> the
>>>> translation to a Request Object URI, so I'm kind of curious where my
>>>> vision differs from reality.
>>>>
>>>> The third paragraph seems to mostly just be describing the procedure of
>>>> how this flow works, which would not necessarily be specific to the
>>>> privacy considerations section.
>>>>
>>>> Section 12.2.2
>>>>
>>>> Even if the protected resource does not include a personally
>>>> identifiable information, it is sometimes possible to identify the
>>>> user through the Request Object URI if persistent per-user Request
>>>> Object URI is used. A third party may observe it through browser
>>>>
>>>> nit: need an article for "persistent per-user Request Object URI" (or
>>>> make it plural, as "URIs are used").
>>>>
>>>> Therefore, per-user Request Object URI should be avoided.
>>>>
>>>> nit: I think this is better as "static per-user Requeste Object URIs"
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
