Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

2014-09-23 Thread Mike Jones
FYI, the -32 and -26 drafts now use the terms "Unsecured JWS" and "Unsecured 
JWT".

-Original Message-
From: jose [mailto:jose-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Friday, September 19, 2014 11:17 AM
To: Warren Kumari
Cc: sec...@ietf.org; Richard Barnes; 
draft-ietf-oauth-json-web-token@tools.ietf.org; j...@ietf.org; Brian 
Campbell; oauth@ietf.org
Subject: Re: [jose] alternative term to "plaintext" for the "none" alg (was Re: 
[OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)

This was discussed in the thread 
http://www.ietf.org/mail-archive/web/oauth/current/msg11315.html and prior to 
that, as JOSE issue #17 http://trac.tools.ietf.org/wg/jose/trac/ticket/17.

-Original Message-
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Friday, September 19, 2014 10:52 AM
To: Mike Jones
Cc: Richard Barnes; Brian Campbell; 
draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org; 
j...@ietf.org; sec...@ietf.org
Subject: Re: alternative term to "plaintext" for the "none" alg (was Re: 
[OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)

On Wed, Sep 17, 2014 at 12:40 PM, Mike Jones  
wrote:
> Yes, this was already extensively discussed.  It was covered in issue
> #36
> http://trac.tools.ietf.org/wg/jose/trac/ticket/36 and the related 
> working group e-mail thread.  It was also a topic during multiple 
> interim working group calls.  As noted by Karen O’Donoghue (one of the
> chairs) in the issue description “Note: There was extensive discussion 
> on the mailing list, and the rough consensus of the working group was 
> to leave "none" in the document.”  As part of the resolution agreed to 
> by the working group, the security considerations text at 
> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#sec
> tion-8.5
> was added.

That seems to be mainly talking about the "alg": "none" / null cipher bit.

I was specifically speaking to:

5.3.  Replicating Claims as Header Parameters

.

   This specification allows Claims present in the JWT Claims Set to be
   replicated as Header Parameters in a JWT that is a JWE, as needed by
   the application.  If such replicated Claims are present, the
   application receiving them SHOULD verify that their values are
   identical, unless the application defines other specific processing
   rules for these Claims.  It is the responsibility of the application
   to ensure that only claims that are safe to be transmitted in an
   unencrypted manner are replicated as Header Parameter values in the
   JWT.

.


Having the claims appear in 2 places seems like bad mojo - but, if this was 
discussed, and people are OK with it,...

W






>
>
>
> -- Mike
>
>
>
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Wednesday, September 17, 2014 4:40 AM
> To: Richard Barnes
> Cc: Brian Campbell; Mike Jones;
> draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org; 
> j...@ietf.org; sec...@ietf.org
> Subject: Re: alternative term to "plaintext" for the "none" alg (was Re:
> [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)
>
>
> On Tuesday, September 16, 2014, Richard Barnes  wrote:
>
> I will re-iterate here my strong preference that an "unsecured" or 
> "plaintext" JWS object be syntactically distinct from a real JWS object.
> E.g. by having two dot-separated components instead of three.
>
>
>
> So, *I* was just grumping about the term used in the draft, but yes, 
> these should (IMO, etc) be different.
>
>
>
> I'm also still uncomfortable about the "you can have the same 
> information in the "secured" and "unsecured" section, but the secured 
> one shold be trusted more bit. This seems like it will end in fail.
> (Apologies if this was already discussed and I missed it, and for 
> rushed tone of mail,
> traveling...)
>
>
>
> W
>
>
>
>
>
> Beyond that, seems like just shuffling deck chairs.
>
>
>
> On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell 
> 
> wrote:
>
> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.
>
>
> I agree that "plaintext” is not the most intuitive wording choice and 
> that "unsecured" might better convey what's going on with the "none"
> JWS algorithm.
>
> Mike mentioned that, if this change is made in JWT, there are parallel 
> changes in JWS. But note that there are also such changes in JWA (more 
> than in JWS actually).
>
>
>
> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones 
> 
> wrote:
>
> -Original Message-
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Monday, September 01, 2014 3:40 PM
> To: sec...@ietf.org;
> draft-ietf-oauth-json-web-token@tools.ietf.org
> Subject: Review of: draft-ietf-oauth-json-web-token
>
> I'm a little confused by something in the Terminology section (Section 2):
>
> Plaintext JWT
>
> A JWT whose Claims are not integrity protected or encrypted.
>
> The term plaintext to me means something like "is readable without 
> decrypting / much decodin

Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

2014-09-19 Thread Mike Jones
This was discussed in the thread 
http://www.ietf.org/mail-archive/web/oauth/current/msg11315.html and prior to 
that, as JOSE issue #17 http://trac.tools.ietf.org/wg/jose/trac/ticket/17.

-Original Message-
From: Warren Kumari [mailto:war...@kumari.net] 
Sent: Friday, September 19, 2014 10:52 AM
To: Mike Jones
Cc: Richard Barnes; Brian Campbell; 
draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org; 
j...@ietf.org; sec...@ietf.org
Subject: Re: alternative term to "plaintext" for the "none" alg (was Re: 
[OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)

On Wed, Sep 17, 2014 at 12:40 PM, Mike Jones  
wrote:
> Yes, this was already extensively discussed.  It was covered in issue 
> #36
> http://trac.tools.ietf.org/wg/jose/trac/ticket/36 and the related 
> working group e-mail thread.  It was also a topic during multiple 
> interim working group calls.  As noted by Karen O’Donoghue (one of the 
> chairs) in the issue description “Note: There was extensive discussion 
> on the mailing list, and the rough consensus of the working group was 
> to leave "none" in the document.”  As part of the resolution agreed to 
> by the working group, the security considerations text at
> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#sec
> tion-8.5
> was added.

That seems to be mainly talking about the "alg": "none" / null cipher bit.

I was specifically speaking to:

5.3.  Replicating Claims as Header Parameters

.

   This specification allows Claims present in the JWT Claims Set to be
   replicated as Header Parameters in a JWT that is a JWE, as needed by
   the application.  If such replicated Claims are present, the
   application receiving them SHOULD verify that their values are
   identical, unless the application defines other specific processing
   rules for these Claims.  It is the responsibility of the application
   to ensure that only claims that are safe to be transmitted in an
   unencrypted manner are replicated as Header Parameter values in the
   JWT.

.


Having the claims appear in 2 places seems like bad mojo - but, if this was 
discussed, and people are OK with it,...

W






>
>
>
> -- Mike
>
>
>
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Wednesday, September 17, 2014 4:40 AM
> To: Richard Barnes
> Cc: Brian Campbell; Mike Jones;
> draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org; 
> j...@ietf.org; sec...@ietf.org
> Subject: Re: alternative term to "plaintext" for the "none" alg (was Re:
> [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)
>
>
> On Tuesday, September 16, 2014, Richard Barnes  wrote:
>
> I will re-iterate here my strong preference that an "unsecured" or 
> "plaintext" JWS object be syntactically distinct from a real JWS object.
> E.g. by having two dot-separated components instead of three.
>
>
>
> So, *I* was just grumping about the term used in the draft, but yes, 
> these should (IMO, etc) be different.
>
>
>
> I'm also still uncomfortable about the "you can have the same 
> information in the "secured" and "unsecured" section, but the secured 
> one shold be trusted more bit. This seems like it will end in fail. 
> (Apologies if this was already discussed and I missed it, and for 
> rushed tone of mail,
> traveling...)
>
>
>
> W
>
>
>
>
>
> Beyond that, seems like just shuffling deck chairs.
>
>
>
> On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell 
> 
> wrote:
>
> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.
>
>
> I agree that "plaintext” is not the most intuitive wording choice and 
> that "unsecured" might better convey what's going on with the "none" 
> JWS algorithm.
>
> Mike mentioned that, if this change is made in JWT, there are parallel 
> changes in JWS. But note that there are also such changes in JWA (more 
> than in JWS actually).
>
>
>
> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones 
> 
> wrote:
>
> -Original Message-
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Monday, September 01, 2014 3:40 PM
> To: sec...@ietf.org; 
> draft-ietf-oauth-json-web-token@tools.ietf.org
> Subject: Review of: draft-ietf-oauth-json-web-token
>
> I'm a little confused by something in the Terminology section (Section 2):
>
> Plaintext JWT
>
> A JWT whose Claims are not integrity protected or encrypted.
>
> The term plaintext to me means something like "is readable without 
> decrypting / much decoding" (something like, if you cat the file to a 
> terminal, you will see the information). Integrity protecting a string 
> doesn't make it not easily readable. If this document / JOSE uses 
> "plaintext" differently (and a quick skim didn't find anything about
>
> this) it might be good to clarify. Section 6 *does* discuss plaintext 
> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term 
> "plaintext"
> here.
>
>
>
> I’ve discussed this with the other document editors and we agree wit

Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

2014-09-19 Thread Warren Kumari
On Wed, Sep 17, 2014 at 12:40 PM, Mike Jones
 wrote:
> Yes, this was already extensively discussed.  It was covered in issue #36
> http://trac.tools.ietf.org/wg/jose/trac/ticket/36 and the related working
> group e-mail thread.  It was also a topic during multiple interim working
> group calls.  As noted by Karen O’Donoghue (one of the chairs) in the issue
> description “Note: There was extensive discussion on the mailing list, and
> the rough consensus of the working group was to leave "none" in the
> document.”  As part of the resolution agreed to by the working group, the
> security considerations text at
> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-8.5
> was added.

That seems to be mainly talking about the "alg": "none" / null cipher bit.

I was specifically speaking to:

5.3.  Replicating Claims as Header Parameters

.

   This specification allows Claims present in the JWT Claims Set to be
   replicated as Header Parameters in a JWT that is a JWE, as needed by
   the application.  If such replicated Claims are present, the
   application receiving them SHOULD verify that their values are
   identical, unless the application defines other specific processing
   rules for these Claims.  It is the responsibility of the application
   to ensure that only claims that are safe to be transmitted in an
   unencrypted manner are replicated as Header Parameter values in the
   JWT.

.


Having the claims appear in 2 places seems like bad mojo - but, if
this was discussed, and people are OK with it,...

W






>
>
>
> -- Mike
>
>
>
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Wednesday, September 17, 2014 4:40 AM
> To: Richard Barnes
> Cc: Brian Campbell; Mike Jones;
> draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org;
> j...@ietf.org; sec...@ietf.org
> Subject: Re: alternative term to "plaintext" for the "none" alg (was Re:
> [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)
>
>
> On Tuesday, September 16, 2014, Richard Barnes  wrote:
>
> I will re-iterate here my strong preference that an "unsecured" or
> "plaintext" JWS object be syntactically distinct from a real JWS object.
> E.g. by having two dot-separated components instead of three.
>
>
>
> So, *I* was just grumping about the term used in the draft, but yes, these
> should (IMO, etc) be different.
>
>
>
> I'm also still uncomfortable about the "you can have the same information in
> the "secured" and "unsecured" section, but the secured one shold be trusted
> more bit. This seems like it will end in fail. (Apologies if this was
> already discussed and I missed it, and for rushed tone of mail,
> traveling...)
>
>
>
> W
>
>
>
>
>
> Beyond that, seems like just shuffling deck chairs.
>
>
>
> On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell 
> wrote:
>
> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.
>
>
> I agree that "plaintext” is not the most intuitive wording choice and that
> "unsecured" might better convey what's going on with the "none" JWS
> algorithm.
>
> Mike mentioned that, if this change is made in JWT, there are parallel
> changes in JWS. But note that there are also such changes in JWA (more than
> in JWS actually).
>
>
>
> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones 
> wrote:
>
> -Original Message-
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Monday, September 01, 2014 3:40 PM
> To: sec...@ietf.org; draft-ietf-oauth-json-web-token@tools.ietf.org
> Subject: Review of: draft-ietf-oauth-json-web-token
>
> I'm a little confused by something in the Terminology section (Section 2):
>
> Plaintext JWT
>
> A JWT whose Claims are not integrity protected or encrypted.
>
> The term plaintext to me means something like "is readable without
> decrypting / much decoding" (something like, if you cat the file to a
> terminal, you will see the information). Integrity protecting a string
> doesn't make it not easily readable. If this document / JOSE uses
> "plaintext" differently (and a quick skim didn't find anything about
>
> this) it might be good to clarify. Section 6 *does* discuss plaintext JWTs,
> but doesn't really clarify the (IMO) unusual meaning of the term "plaintext"
> here.
>
>
>
> I’ve discussed this with the other document editors and we agree with you
> that “plaintext” is not the most intuitive wording choice in this context.
> Possible alternative terms are “Unsecured JWT” or “Unsigned JWT”.  I think
> that “Unsecured JWT” is probably the preferred term, since JWTs that are
> JWEs are also unsigned, but they are secured.  Working group – are you OK
> with this possible terminology change?  (Note that the parallel change
> “Plaintext JWS” -> “Unsecured JWS” would also be made in the JWS spec.)
>
>
>
>
> ___
> jose mailing list
> j...@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
>
> --
> I don't think the 

Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

2014-09-17 Thread Mike Jones
Yes, this was already extensively discussed.  It was covered in issue #36 
http://trac.tools.ietf.org/wg/jose/trac/ticket/36 and the related working group 
e-mail thread.  It was also a topic during multiple interim working group 
calls.  As noted by Karen O’Donoghue (one of the chairs) in the issue 
description “Note: There was extensive discussion on the mailing list, and the 
rough consensus of the working group was to leave "none" in the document.”  As 
part of the resolution agreed to by the working group, the security 
considerations text at 
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-8.5 
was added.

-- Mike

From: Warren Kumari [mailto:war...@kumari.net]
Sent: Wednesday, September 17, 2014 4:40 AM
To: Richard Barnes
Cc: Brian Campbell; Mike Jones; 
draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org; 
j...@ietf.org; sec...@ietf.org
Subject: Re: alternative term to "plaintext" for the "none" alg (was Re: 
[OAUTH-WG] Review of: draft-ietf-oauth-json-web-token)

On Tuesday, September 16, 2014, Richard Barnes 
mailto:r...@ipv.sx>> wrote:
I will re-iterate here my strong preference that an "unsecured" or "plaintext" 
JWS object be syntactically distinct from a real JWS object.  E.g. by having 
two dot-separated components instead of three.

So, *I* was just grumping about the term used in the draft, but yes, these 
should (IMO, etc) be different.

I'm also still uncomfortable about the "you can have the same information in 
the "secured" and "unsecured" section, but the secured one shold be trusted 
more bit. This seems like it will end in fail. (Apologies if this was already 
discussed and I missed it, and for rushed tone of mail, traveling...)

W


Beyond that, seems like just shuffling deck chairs.

On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell 
>
 wrote:
cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.

I agree that "plaintext” is not the most intuitive wording choice and that 
"unsecured" might better convey what's going on with the "none" JWS algorithm.
Mike mentioned that, if this change is made in JWT, there are parallel changes 
in JWS. But note that there are also such changes in JWA (more than in JWS 
actually).

On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones 
>
 wrote:

-Original Message-
From: Warren Kumari 
[mailto:war...@kumari.net]
Sent: Monday, September 01, 2014 3:40 PM
To: sec...@ietf.org; 
draft-ietf-oauth-json-web-token@tools.ietf.org
Subject: Review of: draft-ietf-oauth-json-web-token

I'm a little confused by something in the Terminology section (Section 2):

Plaintext JWT

A JWT whose Claims are not integrity protected or encrypted.

The term plaintext to me means something like "is readable without decrypting / 
much decoding" (something like, if you cat the file to a terminal, you will see 
the information). Integrity protecting a string doesn't make it not easily 
readable. If this document / JOSE uses "plaintext" differently (and a quick 
skim didn't find anything about

this) it might be good to clarify. Section 6 *does* discuss plaintext JWTs, but 
doesn't really clarify the (IMO) unusual meaning of the term "plaintext" here.



I’ve discussed this with the other document editors and we agree with you that 
“plaintext” is not the most intuitive wording choice in this context.  Possible 
alternative terms are “Unsecured JWT” or “Unsigned JWT”.  I think that 
“Unsecured JWT” is probably the preferred term, since JWTs that are JWEs are 
also unsigned, but they are secured.  Working group – are you OK with this 
possible terminology change?  (Note that the parallel change “Plaintext JWS” -> 
“Unsecured JWS” would also be made in the JWS spec.)



___
jose mailing list
j...@ietf.org
https://www.ietf.org/mailman/listinfo/jose



--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Re: [OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

2014-09-17 Thread Warren Kumari
On Tuesday, September 16, 2014, Richard Barnes  wrote:

> I will re-iterate here my strong preference that an "unsecured" or
> "plaintext" JWS object be syntactically distinct from a real JWS object.
> E.g. by having two dot-separated components instead of three.
>

So, *I* was just grumping about the term used in the draft, but yes, these
should (IMO, etc) be different.

I'm also still uncomfortable about the "you can have the same information
in the "secured" and "unsecured" section, but the secured one shold be
trusted more bit. This seems like it will end in fail. (Apologies if this
was already discussed and I missed it, and for rushed tone of mail,
traveling...)

W



> Beyond that, seems like just shuffling deck chairs.
>
> On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell <
> bcampb...@pingidentity.com
> > wrote:
>
>> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.
>>
>> I agree that "plaintext” is not the most intuitive wording choice and
>> that "unsecured" might better convey what's going on with the "none" JWS
>> algorithm.
>>
>> Mike mentioned that, if this change is made in JWT, there are parallel
>> changes in JWS. But note that there are also such changes in JWA (more than
>> in JWS actually).
>>
>> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones > > wrote:
>>
>>>  -Original Message-
>>> From: Warren Kumari [mailto:war...@kumari.net
>>> ]
>>> Sent: Monday, September 01, 2014 3:40 PM
>>> To: sec...@ietf.org ;
>>> draft-ietf-oauth-json-web-token@tools.ietf.org
>>> 
>>> Subject: Review of: draft-ietf-oauth-json-web-token
>>>
>>> I'm a little confused by something in the Terminology section (Section
>>> 2):
>>>
>>> Plaintext JWT
>>>
>>> A JWT whose Claims are not integrity protected or encrypted.
>>>
>>> The term plaintext to me means something like "is readable without
>>> decrypting / much decoding" (something like, if you cat the file to a
>>> terminal, you will see the information). Integrity protecting a string
>>> doesn't make it not easily readable. If this document / JOSE uses
>>> "plaintext" differently (and a quick skim didn't find anything about
>>>
>>> this) it might be good to clarify. Section 6 *does* discuss plaintext
>>> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term
>>> "plaintext" here.
>>>
>>>
>>>
>>> I’ve discussed this with the other document editors and we agree with
>>> you that “plaintext” is not the most intuitive wording choice in this
>>> context.  Possible alternative terms are “Unsecured JWT” or “Unsigned
>>> JWT”.  I think that “Unsecured JWT” is probably the preferred term, since
>>> JWTs that are JWEs are also unsigned, but they are secured.  Working group
>>> – are you OK with this possible terminology change?  (Note that the
>>> parallel change “Plaintext JWS” -> “Unsecured JWS” would also be made in
>>> the JWS spec.)
>>>
>>>
>>>
>>
>> ___
>> jose mailing list
>> j...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


[OAUTH-WG] alternative term to "plaintext" for the "none" alg (was Re: Review of: draft-ietf-oauth-json-web-token)

2014-09-08 Thread Brian Campbell
cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA.

I agree that "plaintext” is not the most intuitive wording choice and that
"unsecured" might better convey what's going on with the "none" JWS
algorithm.

Mike mentioned that, if this change is made in JWT, there are parallel
changes in JWS. But note that there are also such changes in JWA (more than
in JWS actually).

On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones 
wrote:

>  -Original Message-
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Monday, September 01, 2014 3:40 PM
> To: sec...@ietf.org; draft-ietf-oauth-json-web-token@tools.ietf.org
> Subject: Review of: draft-ietf-oauth-json-web-token
>
> I'm a little confused by something in the Terminology section (Section 2):
>
> Plaintext JWT
>
> A JWT whose Claims are not integrity protected or encrypted.
>
> The term plaintext to me means something like "is readable without
> decrypting / much decoding" (something like, if you cat the file to a
> terminal, you will see the information). Integrity protecting a string
> doesn't make it not easily readable. If this document / JOSE uses
> "plaintext" differently (and a quick skim didn't find anything about
>
> this) it might be good to clarify. Section 6 *does* discuss plaintext
> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term
> "plaintext" here.
>
>
>
> I’ve discussed this with the other document editors and we agree with you
> that “plaintext” is not the most intuitive wording choice in this context.
> Possible alternative terms are “Unsecured JWT” or “Unsigned JWT”.  I think
> that “Unsecured JWT” is probably the preferred term, since JWTs that are
> JWEs are also unsigned, but they are secured.  Working group – are you OK
> with this possible terminology change?  (Note that the parallel change
> “Plaintext JWS” -> “Unsecured JWS” would also be made in the JWS spec.)
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth