Subject: [jose] JW* length constraints?

From: Richard L. Barnes <[email-masked]>
Date: Tue, 10 Apr 2012 09:13:58 -0400

Hey all,

One of the requirements noted in the use cases document is that in some cases, JOSE objects will need to be encoded for transmission in URIs, so they need to be short.  This requirement, as I recall, was based on the idea that JOSE would be used to construct tokens for use in OAuth. 

However, I just read through the OAuth spec, and there doesn't seem to be any point where tokens are passed in URIs.  (NB: At least *access* tokens, which is what I understood to be the problem.)  When they're issued to the client, they're passed in an HTTP entity body, and when they're used by the client, they're passed in an Authorization header.

So is there really a length constraint here?

--Richard

---

From: Brian Campbell <[email-masked]>
Date: Tue, 10 Apr 2012 09:17:15 -0600

In practice there are often limitations on the size of HTTP headers so
length is still a consideration in that respect.

There are a couple different flows in OAuth and access tokens can be passed
in URIs when using the so called implicit grant - see the example in
http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.2.2 where the
access token is passes in the fragment

OpenID Connect, which builds on OAuth, also has some constructs similar to
the implicit grant where tokens (access and another type called the id
token which is a JW*) are passed in the fragment of the URI.

So I do think the length constraints are still valid.

On Tue, Apr 10, 2012 at 7:13 AM, Richard L. Barnes <[email-masked]> wrote:

> Hey all,
>
> One of the requirements noted in the use cases document is that in some
> cases, JOSE objects will need to be encoded for transmission in URIs, so
> they need to be short.  This requirement, as I recall, was based on the
> idea that JOSE would be used to construct tokens for use in OAuth.
>
> However, I just read through the OAuth spec, and there doesn't seem to be
> any point where tokens are passed in URIs.  (NB: At least *access* tokens,
> which is what I understood to be the problem.)  When they're issued to the
> client, they're passed in an HTTP entity body, and when they're used by the
> client, they're passed in an Authorization header.
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 10 Apr 2012 15:23:38 +0000

And sometimes tokens are passed as query parameters, per Section 3 of http://developers.facebook.com/docs/authentication/canvas/ and per http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-18#section-2.3.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, April 10, 2012 8:17 AM
To: Richard L. Barnes
Cc: [email-masked]
Subject: Re: [jose] JW* length constraints?

In practice there are often limitations on the size of HTTP headers so length is still a consideration in that respect.

There are a couple different flows in OAuth and access tokens can be passed in URIs when using the so called implicit grant - see the example in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.2.2 where the access token is passes in the fragment

OpenID Connect, which builds on OAuth, also has some constructs similar to the implicit grant where tokens (access and another type called the id token which is a JW*) are passed in the fragment of the URI.

So I do think the length constraints are still valid.
On Tue, Apr 10, 2012 at 7:13 AM, Richard L. Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Hey all,

--Richard
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Apr 2012 12:32:55 -0300

In the implicit flow they are passed in the URI fragment from the Authorization server to the client.

Agreed mostly they are passed to RS as headers.  Though there also limits to header size in many environments.

John B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 10 Apr 2012 17:55:28 -0400

Thanks all.  Understand better now.
--Richard