Thanks for the responses on this, it is helpful to see them from a
range of folks.


On Mon, Apr 28, 2014 at 10:07 AM, Justin Richer <[email protected]> wrote:
> +1
>
> Basically, JOSE defines both crypto processes and container mechanisms for
> those processes. "alg:none" lets you use the container without the crypto in
> a way that's compatible with using the same contianer with crypto. Code
> reuse and parallelism are awesome. But by explicitly calling out that a
> thing is unsigned, an app can decide whether or not it likes unsigned stuff
> and act accordingly.
>
>  -- Justin
>
>
>
> On 04/25/2014 06:17 PM, Brian Campbell wrote:
>
> Plaintext JWSs haven't been free of controversy but the topic has been
> discussed many times and the [rough] consensus of the WG is that the "none"
> JWS alg is useful. It is in use by the finalized versions of OpenID Connect,
> as Vladimir has alluded to. And it has been fairly wildly deployed in
> production use.
>
> The "Plaintext JWS Security Considerations" in section 8.5 of JWA [1]
> represents the consensus the WG came to, which keeps the "none" alg but
> mandates that implementations "MUST NOT accept such objects as valid unless
> the application specifies that it is acceptable for a specific object."
>
> [1]
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-8.5
>
> Vladimir
> On Fri, Apr 25, 2014 at 2:51 PM, Kathleen Moriarty
> <[email protected]> wrote:
>>
>> Thanks, Vladimir.
>>
>> Is there consensus in the WG that this is the right thing to do?  I'm
>> expecting some push-back on this one and want to make sure it has
>> consensus behind it.  I have heard of a couple of objections already.
>>
>> On Thu, Apr 17, 2014 at 2:10 PM, Vladimir Dzhuvinov
>> <[email protected]> wrote:
>> >> 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?
>> >
>> > Yes, securing the JWS message with TLS for instance, as Mike just
>> > pointed
>> > out in the his response.
>> >
>> > JWT-encoded ID tokens in OpenID Connect is one such example, but only
>> > when
>> > the token is returned from the OAuth 2.0 token endpoint where TLS is
>> > mandatory, clients can then register to receive plaintext ID tokens:
>> >
>> > http://openid.net/specs/openid-connect-core-1_0.html#IDToken
>> >
>> >
>> > There is a section in the JWA spec to instruct developers of the various
>> > security
>> > considerations regarding use of "none" alg JWS:
>> >
>> >
>> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-8.5
>> >
>> >
>> > Vladimir
>> >
>> >
>> >
>> >> On Thu, Apr 17, 2014 at 12:57 PM, Vladimir Dzhuvinov <
>> >> [email protected]> 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.
>> >> > >
>> >> >
>> >> > 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
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> jose mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
>



-- 

Best regards,
Kathleen

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to