Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 03 Jul 2019 11:59:05 -0700

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:
----------------------------------------------------------------------

My apologies; my previous position was incomplete.  Updated to note
namespacing issues, and one minor terminology nit about "DNS-ID".

There seem to be some pretty serious namespacing issues that are not
discussed at all in this document.  Specifically, using JWT as a
container for OAuth 2.0 authorization request parameters (including
extension parameters) introduces the usage of many new names (of JSON
name/value pairs) into the JWT claims namespace.  Furthermore, the
addition is not bounded, as any new OAuth extension parameters are
implicitly permitted to be used as well!  The IANA Considerations make
no mention of the collapsed namespace for JWT claims and OAuth 2.0
(authorization request) parameters, leaving substantial potential for
collisions in the future.
Relatedly, using "application/jwt" as the Content-type of the
HTTP response from dereferencing the request_uri with no explicit
indication of the type/profile of JWT used (whether in the content type
or in the JWT claims themselves) gives some risk of misinterpretation of
the content.  Consider, for example, when that request_uri is
dereferenced not by the authorization server in the process of
fulfilling an authorization request, but instead by some other service
that expects a different type of JWT.

This second point 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.

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?

----------------------------------------------------------------------
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 8

   HTTP clients MUST also verify the TLS server certificate, using
   subjectAltName dNSName identities as described in [RFC6125], to avoid
   man-in-the-middle attacks.  The rules and guidelines defined in

It's probably easier to just say "using DNS-ID [RFC6125], to avoid
man-in-the-middle attacks".

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".

Section 13

Are there two different paragraphs for "contributions from the OAuth WG
members"?  Are they reflecting different types of contribution?

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 26 Jul 2019 14:23:09 -0400

Thanks very much for the comments.
Here are my responses to your comments.

> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

The simplest solution probably is to register the authorization request
parameters to the JWT Claims registry.
According to my checking, the relevant but not yet registered parameters
are:

Claim Name: "code_challenge"
Claim Description: OAuth PKCE Code Challenge
Change Controller: IESG
Specification Document(s): Section 3 of RFC 7636

Claim Name: "code_challenge_method"
Claim Description: OAuth PKCE Code Challenge
Change Controller: IESG
Specification Document(s): Section 3 of RFC 7636

Claim Name: "redirect_uri"
Claim Description: OAuth Redirection URI
Change Controller: IETF
Specification Document(s): Section 4.1.1 of RFC 6749

Claim Name: "response_type"
Claim Description: OAuth Authorization Response type
Change Controller: IETF
Specification Document(s): Section 3.1.1 of RFC 6749

Claim Name: "state"
Claim Description: OAuth state parameter
Change Controller: IETF
Specification Document(s): Section 4.1.1 of RFC 6749

Claim Name: "vtr"
Claim Description: Vector of Trust request
Change Controller: IESG
Specification Document(s): Section 4.1 of RFC 8485

> that expects a different type of JWT.

I am making the change to "application/oauth-authz-req+jwt" and add IANA
request.

> dialogue can/should be skipped; do we need to keep this example?

I have actually deliberately put this text as there seem to be some
disconnect between the engineering community and the privacy regulators
community. Asking for "consent" is something that should be considered as
an exception and should use other lawful basis if possible as UK ICO (The
data protection regulator in the UK) advises. As the editor of "ISO/IEC
29184 Privacy notice and consent", which is being developed with close
coordination with regulators such as European Data Protection Board, I
would have to agree to that position and I took OAuth JAR as one of the
opportunity to call it out. I will add some text explaining it such as:

In some cases, it is deemed harmful to ask for consent when it is not
necessary: i.e., the processing is performed under other lawful basis than
consent, as it would make the consent, that should be an exception, stand
out less. Under such circumstances, this mechanism can be used to skip the
authorization dialogue.

Thanks. I will make the change.

> maybe it's a fourth party?)

It is a fourth party, e.g., a trust framework provider or an information
fiduciary.
The text need to be modified though as I found an error.
Since now all the OAuth Request parameters must be in the request object,
only the pattern that can be supported for something like this is to push
the request object to the TFP and have the TFP check if it meets the policy
and return request_uri only it is evelauted as OK.

> Abstract), so I'd suggest "passing the request by reference".

Thanks. I will make the change.

> with the associated signing and encryption methods [RFC7515] [RFC7516]."

Thanks. I will make the change.

> of course be TLS termination earlier than the user-agent in some cases,

Thanks. I will make the change.

> overhead of JWS/JWE cryptography on top of TLS"?

Thanks. I will make the change.

> RFC 8174 has updated BCP 14 boilerplate text to use.

Thanks. I will make the change.

> nit: should this section be 2.3 to get wrapped into "terminology"?

It could, but I suppose it could be as is.

> are largely common knowledge at this point.

Hopefully, they are public knowledge ...

> the "request" and "request_uri" query parameters to  find the Request

Thanks. I will make the description more exact.

> nit: maybe "the JWT claims of the object"?

Thanks. I will probably make it "the JWT claims of the request object."

> nit: I  think we want "This JSON [RFC7159] object".

Thanks. I will fix it as suggested.

> seem to talk about it.  (Note that this example is used later on as

It is an extension parameter that is registered in the OAuth authorization
request registry.
It is defined in OpenID Connect Core and OIDF is in the process of
registering it to the JWT Claims registry as well. I have put them to show
that extension parameters can also be used in the request object. Having
said that, they may be confusing. I should just remove them.

> It sounds like a link to https://www.w3.org/TR/capability-urls/ might

Thanks. I will add it.

> for backwards compatibility?

It is probably be better to remove them as they are not allowed to be used.

> entropy in this request that we have in the previous example(s)?

Thanks for pointing out. I will fix it. (The previous example also needs to
be changed.)

> of draft-ietf-oauth-jwt-bcp?

Yes. RFC7591 combined with some of the OAuth Dynamic Client Registration
Metadata registry forms the concept. RFC7591 allows clients to register the
claims that is in the OAuth Dynamic Client Registration Metadata registry.
The registry has

   - request_object_signing_alg
   - request_object_encryption_alg

besides others. Having said that, it is a bit obscure so I probably should
put some more explanation around it.

> man-in-the-middle attacks".

Thanks. I will do so.

> also point at this document.)

OIDC is an extension of OAuth and it should be fine as is.
What we need to be careful is that there will be no conflict going forward.
I will put the instruction update that will be provided by Mike (Jones).

> We probably also want to reference draft-ietf-oauth-jwt-bcp.

Thanks. I will put the reference as draft.

> okay to talk about just "signed or encrypted" here?

Very good catch. It should be changed to align with other sections.

> which will always be there.

You are right. This one should be removed.

> also use an editing pass.)

Thanks for pointing it out. Changing as follows would be ok?

(d) When Authorization Server is providing an endpoint that provides a
Request Object URI in exchange for a Request Object,
the Authorization Server MUST perform Client
Authentication to accept the Request Object and bind the Client
Identifier to the Request Object URI it is providing. Since
Request Object URI can be replayed, the lifetime of the Request
Object URI MUST be short and preferably one-time use. The
entropy of the Request Object URI MUST be sufficiently large.
The adequate shortness of the validity and the entropy of the
Request Object URI depends on the risk calculation based on the
value of the resource being protected. A general guidance for
the validity time would be less than a minute and the Request
Object URI is to include a cryptographic random value of 128bit
or more at the time of the writing of this specification.

> actually do its job and not misbehave, right?

Yes. I will add wording around it.

>
> Section 10.3
>
> I'm not entirely sure what "[t]he endpoints that come into question in

Yes. RFC6749, RFC6750, and RFC8414.

>    applies to Authorization Request Object.

In the Authorization request.
I thought it would be too onerous to state

In [RFC6749], while Redirection URI is included in the Authorization
> Request,
> others are not included in the Authorization Request.  As the result, the
> same

Would you like to add "in the Authorization Request" as above?

> It's probably also worth citing the generic URI security considerations

I will do so. Thanks.

> nit: remove the "do" in order to make the construction parallel.

Thanks. I will do so.

> vision differs from reality.

So, I should probably expand the text.
The process is two steps:

1. (Certification Process) The TFP examines the business process of the
client and determines what claims they needs: This is the certification
process. Once the client is certified, then they are issued a client
credential to authenticate against to push request objects to the TFP to
get the request_uri.

2. (Translation Process) The client uses the client credential that it got
to push the request object to the TFP to get the request_uri.

> privacy considerations section.

The third paragraph is also important from the privacy point of view.
In a trust framework that has a policy to only allow TFP vetted request
object,
then the Authorization Server must make sure that it was.
One way to do it is to check the authority section.

> make it plural, as "URIs are used").

Thanks. I will fix it.

> nit: I think this is better as "static per-user Requeste Object URIs".

Thanks. I will fix it.

> members"?  Are they reflecting different types of contribution?

Thanks. I have merged them.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Brian Campbell <[email-masked]>
Date: Fri, 26 Jul 2019 14:47:15 -0600

Nat, you suggest that the "simplest solution probably is to register the
authorization request parameters to the JWT Claims registry." However, as
I've attempted to articulate several times this week (
https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and
muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
even back in 2017 (
https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I
believe the pragmatic solution to this is to register some of the main JWT
claims into the OAuth parameters registry (not the other way around, as
you're suggesting which wouldn't even have caught the one name collision
we've actually had where a draft, more than one actually, wanted to call an
authorization request parameter "aud", which would conflicted with the JWT
claim of the same name and cause big problems when used together with JAR).
I suppose the iron clad way to "fix" this would be to merge the two
registries and keep them in sync forever. But that seems awfully heavy
handed and unnecessary. JAR is a specific application of JWT being used to
convey an OAuth authz request. JAR explicitly uses a few core JWT claims
(aud, iss) and one could reasonably imagine other core ones being used as
well (exp, iat, nbf, jti, etc). An authorization request parameter being
introduced that uses one of those names is far and away the most likely
point of collision (and has already happened, as noted previously). A new
JWT claim being introduced that collides with an existing authorization
request parameter name AND would be used in the context of JAR is far far
less likely to happen. So unlikely, in fact, that I don't think it's
necessary or even useful to pollute the JWT claims registry with the names
of all the authorization request parameters. I happen to be one of the DEs
on the JWT claims registry so, in theory, I have some idea what I'm talking
about here. In theory. And I do have to be upfront at this point and say
that I will push back on a request for registration of a bunch of
authorization request parameters into the JWT claims registry without
without more compelling reason.

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura <[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > the content..  Consider, for example, when that request_uri is
> > nit: "all the parameters" kind of sounds like "all that are defined"..
> > we say down in Sections 5 and 6.3..
> >       "aud": "https://server..example.com <https://server.example.com>",
> >       "redirect_uri": "https://client..example.org/cb
> <https://client.example.org/cb>",
> >       "scope": "openid",
> >       "state": "af0ifjsldkj",
> >       "nonce": "n-0S6_WzA2Mj",
> >       "max_age": 86400
> >      }
> >
> >  "redirect_uri": "https://client.example.org/cb
> <https://client..example.org/cb>",
> >  "scope": "openid",
> >  "state": "af0ifjsldkj",
> >  "nonce": "n-0S6_WzA2Mj",
> >  "max_age": 86400,
> >  "claims":
> >   {
> >    "userinfo":
> >     {
> Thanks for pointing out. I will fix it. (The previous example also needs
> to be changed.)
>
> >
> > Section 6.2
> >
> >    pre-registered algorithm..  The signature MUST be validated against
> > OAuth@ietf..org <[email-masked]>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 27 Jul 2019 02:02:31 -0400

Brian,

Perhaps I should have spelled out what I have stated as "grandfather the
currently registered OAuth Authorization Request parameters into JWT Claims
Registry and keep any incoming OAuth Authz param in sync with the JWT
Claims Registry by creating a modified instruction for IANA processings.

I felt that to find out what is being added to the JWT Claims registry as
potentially OAuth Authz Request extension parameters that are coming in the
future a bit arbitrary and not-so-simple while an instruction to add
incoming OAuth Authz Request parameters to JWT Claims Registry is
deterministic and therefore simple.

On Fri, Jul 26, 2019 at 4:47 PM Brian Campbell <[email-masked]>
wrote:

> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
> and muliple comments on https://bitbucket.org/openid/connect/issues/1019)
> and even back in 2017 (
> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY),
> I believe the pragmatic solution to this is to register some of the main
> JWT claims into the OAuth parameters registry (not the other way around, as
>> It is an extension parameter that is registered in the OAuth
>> authorization request registry.
>> besides others. Having said that, it is a bit obscure so I probably
>> should put some more explanation around it.
>>
>> >
>> > Section 8
>> >
>>> others are not included in the Authorization Request.  As the result,
>>> the same
>> 2. (Translation Process) The client uses the client credential that it
>> got to push the request object to the TFP to get the request_uri.
>>
>> >
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Brian Campbell <[email-masked]>
Date: Sun, 28 Jul 2019 06:25:42 -0600

I'm honestly not sure I follow all that or how it would really work to
prevent name collisions. As a lipnus test, would the one real world
instance of the issue (name collision with 'aud') have been averted by this?

While my understanding is obliviously a requirement here, I do have more
familiarity with this stuff than the average person, so my lack of
understanding might serve as a good indicator about the likely simplicity
and efficacy of what's been suggested.

---

From: n-sakimura <[email-masked]>
Date: Sun, 28 Jul 2019 22:18:29 +0000

Brian,

You are the expert on the particular IANA registries so I probably are missing something.

I was thinking that registering JWT claims to OAuth registry is sufficient till seeing Ben’s comment, and I was tracking that it is being done by Mike as part of the errata process for OIDC Core. However, after reading Ben’s comment that mentioning the OAuth extensions, and I checked that quite a few claims are now being registered to JWT Claims Registry from outside the OAuth community, I started to feel that it may not be sufficient. But I must be missing something as you point out that is still sufficient.

Could you please explain how the collision between the future OAuth extension and JWT claims can be avoided by registering main JWT claims to the OAuth Parameter registry?
If that is the case, I am all for it as then we do not get back to IANA process.

Best,

Nat

Nat Sakimura | 崎村夏彦
Nomura Research Institute

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。

PLEASE READ：This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail.

________________________________
差出人: Brian Campbell <[email-masked]>
送信日時: Saturday, July 27, 2019 5:47:15 AM
宛先: Nat Sakimura <[email-masked]>
CC: Benjamin Kaduk <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; The IESG <[email-masked]>; oauth <[email-masked]>
件名: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura <[email-masked]> wrote:

> claims that is in the OAuth Dynamic Client Registration Metadata registry

---

From: Brian Campbell <[email-masked]>
Date: Mon, 29 Jul 2019 09:48:39 -0600

To be accurate, I'm one of the DEs on the JWT Claims registry
https://www.iana.org/assignments/jwt/jwt.xhtml while Hannes is the DE on
the OAuth Parameters registry
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
FWIW.

To completely lock it all down and absolutely avoid collisions in all cases
(all cases that bother to consult the registries anyway), I suppose the two
registries would need to be reconciled and then kept perfectly in sync
going forward. Or even merged into a single super registry. But, to me
anyway, that seems like a huge PITA that's overkill and doesn't account for
the context of use with respect to likelihood of actual collisions.

JAR is a  specific application of JWT that is being used to convey an OAuth
authz request. The collisions that need to be avoided are in that narrow
context. JAR explicitly uses a few core JWT claims (aud, iss) so those need
to be accounted for by registering them as OAuth authorization request
parameters (with some explanation as such).  And one could reasonably
imagine some of the other core claims which are about the token itself
being used as well (exp, iat, nbf, jti, cnf, etc). So those should probably
be accounted for as well.

But most/all of the other JWT claims that have been registered, the SIP
CSeq numeric header field parameter value for example, are highly unlikely
to ever be used in the context of an OAuth authorization request. So won't
be a collision issue in the narrow context of a JWT secured authorization
request.  I think it's unlikely enough to be an issue that I think it's
sufficient to only register the core meta JWT claim names into the OAuth
parameters registry for the authorization request usage location.

True, that's not 100% guaranteed to guard against all collisions. But I
think it's pragmatic trade off that guards against all likly real world
collisions.

And if we are really worried about avoiding it 100% guaranteed all the
time, then JAR should wrap the authorization request parameters in a JSON
object so they have their own effectively distinct namespace. But I realize
that's a major change at this stage. Which leads me back to looking for a
simple(ish) and pragmatic approach to avoiding actual likely collisions.

On Sun, Jul 28, 2019 at 4:18 PM n-sakimura <[email-masked]> wrote:

> I was thinking that registering JWT claims to OAuth registry is sufficient
> till seeing Ben’s comment, and I was tracking that it is being done by Mike
> as part of the errata process for OIDC Core. However, after reading Ben’s
> comment that mentioning the OAuth extensions, and I checked that quite a
> few claims are now being registered to JWT Claims Registry from outside the
> OAuth community, I started to feel that it may not be sufficient. But I
> must be missing something as you point out that is still sufficient.
>
> Could you please explain how the collision between the future OAuth
> extension and JWT claims can be avoided by registering main JWT claims to
> the OAuth Parameter registry?
> PLEASE READ：This e-mail is confidential and intended for the named
> recipient only. If you are not an intended recipient, please notify the
> sender and delete this e-mail.
>
> ------------------------------
> *差出人:* Brian Campbell <[email-masked]>
> *送信日時:* Saturday, July 27, 2019 5:47:15 AM
> *宛先:* Nat Sakimura <[email-masked]>
> *CC:* Benjamin Kaduk <[email-masked]>; [email-masked] <
> [email-masked]>; [email-masked] <
> [email-masked]>; The IESG <[email-masked]>; oauth <[email-masked]>
> *件名:* Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
>
> and
> I