Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

From: "Vladimir Dzhuvinov" <[email-masked]>
Date: Thu, 17 Apr 2014 09:57:47 -0700

Hi Kathleen,

> Section 3.6 - Can you explain why would this be included?  If you are not going to sign, I am not sure why one would use JOSE at all. 
>  

Perhaps the most popular application of JWS today is to construct JSON
Web Tokens (JWT), such as the ID tokens in OpenID Connect. The JWT spec
permits plain tokens that don't have a signature and this is enabled by
the special case "none" alg in JWS.

Plaintext JWTs are explained here:

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#section-6

Vladimir

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 17 Apr 2014 13:20:45 -0400

Thanks, Vladimir.

How would they be secured then?  With the current threat landscape, it
seems odd that we would be putting forth a method that is not secured?
 Does this rely on transport for security?

On Thu, Apr 17, 2014 at 12:57 PM, Vladimir Dzhuvinov <
[email-masked]> wrote:

> Hi Kathleen,
>
>
> > Section 3.6 - Can you explain why would this be included?  If you are
> not going to sign, I am not sure why one would use JOSE at all.
> >
>

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Apr 2014 18:01:39 +0000

Per the reply in my other note – sometimes it’s fine for parameters encoded in an unsigned JWS not to be secured, just like it’s fine for HTTP request parameters to not be secured.  Signing the set of request parameters strictly adds additional value.

In other use cases, the JWS payload is secured by other means, such as TLS.

“alg”: “none” is in production use for both of these kinds of scenarios.

                                                            -- Mike

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Thursday, April 17, 2014 10:21 AM
To: Vladimir Dzhuvinov
Cc: [email-masked]; Mike Jones; [email-masked]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms

Thanks, Vladimir.

How would they be secured then?  With the current threat landscape, it seems odd that we would be putting forth a method that is not secured?  Does this rely on transport for security?

On Thu, Apr 17, 2014 at 12:57 PM, Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kathleen,

Vladimir

--

Best regards,
Kathleen