There is maybe a need to be more explicit that this alg:none container just means that security will be provided at a different layer rather than having no security at all. I would specifically mention the case of OAuth with the current proof-of-possession work where we are planning to re-use the alg:none mechanism for key transport between the authorization server and the client.
Ciao Hannes On 04/28/2014 04:11 PM, Kathleen Moriarty wrote: > 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 >> >> > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
