Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq

From: Jim Schaad <[email-masked]>
Date: Thu, 1 Nov 2018 16:04:42 +0900

Ok - I'll ask the questions explicitly.

What additional features do you get from the claims that are already defined
for a JWT.  

How do these features relate to the original problem statement of needing
encryption and origination?

Why are these not features that should be in the base OAuth design and thus
part of the OAuth registry?

Jim

From: Mike Jones <[email-masked]> 
Sent: Wednesday, October 31, 2018 9:18 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: 'oauth' <[email-masked]>
Subject: RE: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq

JWT defines a number of standard claims that are used in this application,
including "iss" (issuer), "aud" (audience), etc.  Making the requests a JWT
allows code reuse, rather than having an application-specific signed request
representation that has many of the semantics and fields of a JWT anyway.

It's also worth noting that this practice has been a standard since 2014.
OpenID Connect Core standardized the OAuth signed request format in
https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests.  The
draft-ietf-oauth-jwsreq
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17>  spec is the
OAuth-only version of this already standard and deployed practice.  (There's
other precedents for OAuth subsetting standard OpenID Connect functionality.
For instance, RFC 8414 <https://tools.ietf.org/html/rfc8414>  is the
OAuth-specific subset of the metadata format defined by OpenID Connect
Discovery <https://openid.net/specs/openid-connect-discovery-1_0.html> .)

                                                       -- Mike

-----Original Message-----
From: OAuth <[email-masked] <mailto:[email-masked]> > On
Behalf Of Jim Schaad
Sent: Wednesday, October 31, 2018 8:33 AM
To: [email-masked]
<mailto:[email-masked]> 
Cc: 'oauth' <[email-masked] <mailto:[email-masked]> >
Subject: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq

As part of looking at the issues of using CWTs for this purpose I did some
more reading of the document.  I am having a problem with the understanding
the reasons for using JWT as opposed to just saying that you are going to
use JWS and JWE.  There is nothing in this section that I can see that
points to a reason to be using JWTs as the carrier.  What am I missing?

Jim

_______________________________________________

OAuth mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/oauth>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 1 Nov 2018 09:45:23 -0300

The JWT was done by the OAuth WG.

Some wanted it to be core to OAuth and others wanted it to be entirely
optional so that people would not feel obligated to use it for access
tokens.

JWT is used in a number of OAuth specs now and provides consistency for
some common elements like issuer , audience, and expiery.

Yes we could have started from JWS and redefined those elements but would
then need another IANA registry.

Perhaps I am not understanding what you are getting at.

John B.

On Thu, Nov 1, 2018, 4:04 AM Jim Schaad <[email-masked] wrote:

> Ok – I’ll ask the questions explicitly.
>
>
>
> What additional features do you get from the claims that are already
> defined for a JWT.
>
>
>
> Why are these not features that should be in the base OAuth design and
> thus part of the OAuth registry?
>
>
>
> Jim
>
>
>
>
>
> *From:* Mike Jones <[email-masked]>
> *Sent:* Wednesday, October 31, 2018 9:18 AM
> *To:* Jim Schaad <[email-masked]>;
> [email-masked]
> *Cc:* 'oauth' <[email-masked]>
> *Subject:* RE: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq
>
>
>
> allows code reuse, rather than having an application-specific signed
> request representation that has many of the semantics and fields of a JWT
> anyway.
>
>
>
> OAuth-only version of this already standard and deployed practice.
> (There's other precedents for OAuth subsetting standard OpenID Connect
> functionality.  For instance, RFC 8414
> <https://tools.ietf.org/html/rfc8414> is the OAuth-specific subset of the
> metadata format defined by OpenID Connect Discovery
> <https://openid.net/specs/openid-connect-discovery-1_0.html>.)
>
>
>
>                                                        -- Mike
>
>
>
> From: OAuth <[email-masked]> On Behalf Of Jim Schaad
> [email-masked]