Subject: Re: [jose] Update to Use Cases document for content without integrity protection

From: Mike Jones <[email-masked]>
Date: Tue, 3 Sep 2013 18:23:50 +0000

Thanks for writing this Richard.  I believe it's most of the way there.  I've corrected one problem your proposed prose in the attached version, which is a lightly edited version of your text.  The problem was that you made it sound like Plaintext JWSs were somehow specific to OpenID Connect, whereas they're actually already also used in contexts that are not OpenID Connect.

      <section anchor="unsigned" title="Content without Integrity Protection">
        <t>
                  In some contexts, such as for JSON Web Tokens (JWTs), there is one more requirement in
                  addition to the general considerations for integrity protected content.  Under
                  some circumstances, the recipient of a payload may choose to
                  rely on transport security rather than object security.  For example,
                  if the payload is delivered over a TLS-protected channel, the recipient
                  may regard the protections provided by TLS as sufficient, so
                  JOSE protection would not be required.
                  In this case, integrity protecting the payload is optional.
                  OpenID Connect has two circumstances in which content is optionally signed
                  and a forthcoming OAuth authentication specification uses this capability as well.
        </t>
        <t>
                  However, even in this case, it is desirable to associate some
                  metadata with the payload, such as the content type,
                  or other application-specific metadata.  In a signed or encrypted
                  object, these metadata values could be carried in a header with
                  other metadata required for signing or encryption.  It would thus
                  simplify the design of JWTs and similar applications if
                  there could be a JOSE object representation that does not apply cryptographic
                  protections to its payload, but allows a header to be attached to the
                  payload in the same way as a signed or encrypted object.
        </t>
      </section>

                                                                Thanks,
                                                                -- Mike

P.S.  The attached source also updates the history section both for -05 and for the -04 edits.

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, August 30, 2013 11:57 AM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Update to Use Cases document for content without integrity protection

I have added the following text to my working copy.  Comments welcome.

"""
        <t>
        In the OpenID Connect context, there is one more requirement in
        addition to the general considerations for security tokens.  Under
        some circumstances, the recipient of a JWT token may choose to
        rely on transport security rather than object security.  For example,
        if a token is delivered over a TLS-protected channel, the recipient
        would regard the protections provided by TLS as sufficient, so
        JOSE protection would not be required.
        </t>

        <t>
        However, even in this case, it is desirable to associate some
        metadata with the JWT payload (claim set), such as the content type,
        or other application-specific metadata.  In a signed or encrypted
        object, these metadata values could be carried in a header with
        other metadata required for signing or encryption.  It would thus
        simplify the design of OpenID Connect and similar applications if
        there could be a JOSE object type that does not apply cryptographic
        protections to its payload, but allows a header to be attached to the
        payload in the same way as a signed or encrypted object.
        </t>
"""

On Thu, Aug 29, 2013 at 8:04 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Not ready for prime time

Under some circumstances,  <If you say under some circumstances then those circumstances need to be clearly delineated>Itit is can be useful to be able to represent carry content without integrity protection but with in a way that the same kinds of information about the content that would accompanies integrity protected content can still accompany the non-integrity-protected content. The This information about the content, such as the content type value or application-specification information, is carried as header parameter values. The capability to represent non-integrity-protected content is particularly useful in situations when signing the content may be optional.

<I think given the current way you are trying to get things done, you need to have a justification for the signed and unsigned versions of the message being very similar in nature - otherwise it makes more sense to use the Richard solution of having a different structure for non-integrity protected objects.>

For instance, the The JSON Web Token (JWT) specification enables permits claims to be communicated created that are signed and/or encrypted or that carry no integrity protection. Whether integrity protection is required is dependent upon the application's requirements and the particular usage context. For instance, if If the token content is being communicated over a channel protected with TLS, the application <A description of this application would be useful.  Presumably it needs to be a straight client-server model with no proxies in the middle.>  may be willing to can accept unsigned content based upon a trust decision utilizing a check of the sender's TLS certificate; whereas if the content is being sent over a non-TLS channel, the application may require that the content be signed and/or encrypted. OpenID Connect has two circumstances <What are these circumstances?  Are these cases which should be outlined so that we can see what is happening and why this would be secure?> in which content is optionally signed and a forthcoming OAuth authentication specification uses this capability as well<How does it use this capability?  This would be especially problematic as needing a description given that the OAuth description above would require that the integrity be in existence since the token is transmitted via two untrustworthy parties.>.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Monday, August 26, 2013 1:22 PM

To: Richard Barnes
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Update to Use Cases document for content without integrity protection

The attached versions address these comments - describing a way that applications can know whether integrity protection is needed, describing conveying additional information about the content in header parameters, and listing two different applications using this capability.  Please revise the Use Cases draft accordingly or reply with specific requests requesting further revisions before the document is updated.

                                                            Thanks,
                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, August 21, 2013 9:37 PM
To: Jim Schaad
Cc: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Update to Use Cases document for content without integrity protection

Also: Elaborating on what in the scenario tells the application that it's OK to get "none" from one recipient and not another.

As to whether this is OpenID: Where else is "alg":"none" currently used?  Better to describe a specific use case.

On Wed, Aug 21, 2013 at 7:43 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
That would be a good start

From: Mike Jones [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 21, 2013 4:14 PM
To: Jim Schaad; 'Richard Barnes'
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Update to Use Cases document for content without integrity protection

What additional information would you like to see be included about the use case?  For instance, would you like the examples about header parameter values being included with unsigned content that John mentioned on the call?

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, August 21, 2013 4:11 PM
To: Mike Jones; 'Richard Barnes'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Update to Use Cases document for content without integrity protection

Mike,

I don't think that is really providing the necessary justification.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, August 21, 2013 12:00 PM
To: Richard Barnes
Cc: [email-masked]<mailto:[email-masked]>
Subject: [jose] Update to Use Cases document for content without integrity protection

Per the decision on the call yesterday that we should define a format for representing content without integrity protection, and my action item to produce Use Cases text reflecting this, my proposed text is enclosed.  Richard, I've enclosed edits to -04 that accomplish this.

The additions are enclosed below:

5.9.  Content without Integrity Protection
Under some circumstances, it is useful to be able to represent
Under some circumstances is not very specific.  This is probably not how you want to start this.  You should start this with a more specific case where this is going to be useful.
content without integrity protection in a way that the same kinds of information about the content that would accompany
This is a bit problematic with the original version of how JOSE was specified, but is now ok.  However detail on what types of information are going to be useful really needs to be stated.
integrity protected content can still accompany the non-integrity-protected content. This is particularly true when signing the content may be optional.
This is a security document, it should be more detailed about why it should be optional.
For instance, the JSON Web Token (JWT) specification enables claims to be communicated that are signed and/or encrypted or that carry no integrity protection. Whether integrity protection is required is dependent upon the application's requirements and the particular usage context.
More detail - look at the small device use cases - these are much more detailed about what the use is and what the circumstances are.  The more detail the easier it is for people to understand what is going on and why this is a useful case.
This also needs to have some support about why the difference between the signed and unsigned cases need to have minimal differences in the representation.  Otherwise using an unsigned data structure that is specific to that purpose would be a highly justifiable way to go with this.

Jim

F8
Define a format allowing content without integrity protection to be represented.

Richard, I also commented out the reference to RFC 5083, which wasn't being used in the document.  Finally, I updated the document history section, including adding the entries for the -04 edits, which had been omitted.

                                                                -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Tue, 3 Sep 2013 16:26:56 -0400

It's best to be concrete in this document.  I would like to avoid the "in
some contexts" weasel words.  If you know of some other contexts, I would
be glad to include them.  Otherwise, we'll stick with the example we have.
--Richard

On Tue, Sep 3, 2013 at 2:23 PM, Mike Jones <[email-masked]>wrote:

>  Thanks for writing this Richard.  I believe it’s most of the way there.
> I’ve corrected one problem your proposed prose in the attached version,
> which is a lightly edited version of your text.  The problem was that you
> made it sound like Plaintext JWSs were somehow specific to OpenID Connect,
> whereas they’re actually already also used in contexts that are not OpenID
> Connect.****
>
> ** **
>
>       <section anchor="unsigned" title="Content without Integrity
> Protection">****
>
>         <t>****
>
>                   In some contexts, such as for JSON Web Tokens (JWTs),
> there is one more requirement in ****
>
>                   addition to the general considerations for integrity
> protected content.  Under****
>
>                   some circumstances, the recipient of a payload may
> choose to ****
>
>                   rely on transport security rather than object security.
> For example,****
>
>                   if the payload is delivered over a TLS-protected
> channel, the recipient****
>
>                   may regard the protections provided by TLS as
> sufficient, so ****
>
>                   JOSE protection would not be required.****
>
>                   In this case, integrity protecting the payload is
> optional.****
>
>                   OpenID Connect has two circumstances in which content is
> optionally signed****
>
>                   and a forthcoming OAuth authentication specification
> uses this capability as well. ****
>
>         </t>****
>
>         <t>****
>
>                   However, even in this case, it is desirable to associate
> some ****
>
>                   metadata with the payload, such as the content type,****
>
>                   or other application-specific metadata.  In a signed or
> encrypted ****
>
>                   object, these metadata values could be carried in a
> header with ****
>
>                   other metadata required for signing or encryption.  It
> would thus****
>
> ****
>                   there could be a JOSE object representation that does
> not apply cryptographic****
>
>                   protections to its payload, but allows a header to be
> attached to the****
>
> ****
>         </t>****
>       </section>****
> ** **
>                                                                 Thanks,***
> *
>                                                                 -- Mike***
> *
> ** **
> P.S.  The attached source also updates the history section both for -05
> and for the -04 edits.****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Friday, August 30, 2013 11:57 AM
>
> *To:* Jim Schaad
> *Cc:* Mike Jones; [email-masked]
> *Subject:* Re: [jose] Update to Use Cases document for content without
> integrity protection****
>
> ** **
>
> I have added the following text to my working copy.  Comments welcome.****
>
> ** **
>
> """****
>
>         <t>****
>
>         In the OpenID Connect context, there is one more requirement in **
> **
>
> ****
>         some circumstances, the recipient of a JWT token may choose to ***
> *
>
>         rely on transport security rather than object security.  For
> example,****
>
> ****
>         would regard the protections provided by TLS as sufficient, so ***
> *
>
>         JOSE protection would not be required.****
>
>         </t>****
>
> ** **
>
>         <t>****
>
>         However, even in this case, it is desirable to associate some ****
>
>         metadata with the JWT payload (claim set), such as the content
> type,****
>
> ****
>         object, these metadata values could be carried in a header with **
> **
>
>         other metadata required for signing or encryption.  It would thus*
> ***
>
> ****
> ****
>         protections to its payload, but allows a header to be attached to
> the****
>
>         payload in the same way as a signed or encrypted object.****
>
>         </t>****
>
> """****
>
> ** **
>
> On Thu, Aug 29, 2013 at 8:04 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> Not ready for prime time****
>
> Under some circumstances,  <If you say under some circumstances then
> those circumstances need to be clearly delineated>Itit is can be useful
> to be able to represent carry content without integrity protection but
> with in a way that the same kinds of information about the content that
> would accompanies integrity protected content can still accompany the
> non-integrity-protected content. The This information about the content,
> such as the content type value or application-specification information,
> is carried as header parameter values. The capability to represent
> non-integrity-protected content is particularly useful in situations when
> signing the content may be optional.****
>
> <I think given the current way you are trying to get things done, you need
> to have a justification for the signed and unsigned versions of the message
> being very similar in nature – otherwise it makes more sense to use the
> Richard solution of having a different structure for non-integrity
> protected objects.> ****
>
> For instance, the The JSON Web Token (JWT) specification enables permits
> claims to be communicated created that are signed and/or encrypted or
> that carry no integrity protection. Whether integrity protection is
> required is dependent upon the application's requirements and the
> particular usage context. For instance, if If the token content is being
> communicated over a channel protected with TLS, the application <A
> description of this application would be useful.  Presumably it needs to be
> a straight client-server model with no proxies in the middle.>  may be
> willing to can accept unsigned content based upon a trust decision
> utilizing a check of the sender's TLS certificate; whereas if the content
> is being sent over a non-TLS channel, the application may require that the
> content be signed and/or encrypted. OpenID Connect has two circumstances<What are these circumstances?  Are these cases which should be outlined so
> that we can see what is happening and why this would be secure?> in which
> content is optionally signed and a forthcoming OAuth authentication
> specification uses this capability as well<How does it use this
> capability?  This would be especially problematic as needing a description
> given that the OAuth description above would require that the integrity be
> in existence since the token is transmitted via two untrustworthy parties.>.
> ****
>
>  ****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mike Jones
> *Sent:* Monday, August 26, 2013 1:22 PM****
>
>
> *To:* Richard Barnes
> *Cc:* [email-masked]****
>
> *Subject:* Re: [jose] Update to Use Cases document for content without
> integrity protection****
>
>  ****
>
> The attached versions address these comments – describing a way that
> applications can know whether integrity protection is needed, describing
> conveying additional information about the content in header parameters,
> and listing two different applications using this capability.  Please
> revise the Use Cases draft accordingly or reply with specific requests
> requesting further revisions before the document is updated.****
>
>  ****
>
>                                                             Thanks,****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, August 21, 2013 9:37 PM
> *To:* Jim Schaad
> *Cc:* Mike Jones; [email-masked]
> *Subject:* Re: [jose] Update to Use Cases document for content without
> integrity protection****
>
>  ****
>
> Also: Elaborating on what in the scenario tells the application that it's
> OK to get "none" from one recipient and not another.****
>
>  ****
>
> As to whether this is OpenID: Where else is "alg":"none" currently used?
>  Better to describe a specific use case.****
>
>  ****
>
> On Wed, Aug 21, 2013 at 7:43 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> That would be a good start****
>
>  ****
>
> *From:* Mike Jones [mailto:[email-masked]]
> *Sent:* Wednesday, August 21, 2013 4:14 PM
> *To:* Jim Schaad; 'Richard Barnes'
> *Cc:* [email-masked]
> *Subject:* RE: [jose] Update to Use Cases document for content without
> integrity protection****
>
>  ****
>
> What additional information would you like to see be included about the
> use case?  For instance, would you like the examples about header parameter
> values being included with unsigned content that John mentioned on the call?
> ****
>
>  ****
>
>                                                                 -- Mike***
> *
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Jim Schaad
> *Sent:* Wednesday, August 21, 2013 4:11 PM
> *To:* Mike Jones; 'Richard Barnes'
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Update to Use Cases document for content without
> integrity protection****
>
>  ****
>
> Mike,****
>
>  ****
>
> I don’t think that is really providing the necessary justification.****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Mike Jones
> *Sent:* Wednesday, August 21, 2013 12:00 PM
> *To:* Richard Barnes
> *Cc:* [email-masked]
> *Subject:* [jose] Update to Use Cases document for content without
> integrity protection****
>
>  ****
>
> Per the decision on the call yesterday that we should define a format for
> representing content without integrity protection, and my action item to
> produce Use Cases text reflecting this, my proposed text is enclosed.
>  Richard, I’ve enclosed edits to -04 that accomplish this.****
>
>  ****
>
> The additions are enclosed below:****
>
>  ****
>
> *5.9.  Content without Integrity Protection*****
>
> Under some circumstances, it is useful to be able to represent****
>
> Under some circumstances is not very specific.  This is probably not how
> you want to start this.  You should start this with a more specific case
> where this is going to be useful.****
>
> content without integrity protection in a way that the same kinds of
> information about the content that would accompany****
>
> This is a bit problematic with the original version of how JOSE was
> specified, but is now ok.  However detail on what types of information are
> going to be useful really needs to be stated.****
>
> integrity protected content can still accompany the
> non-integrity-protected content. This is particularly true when signing the
> content may be optional. ****
>
> This is a security document, it should be more detailed about why it
> should be optional.****
>
> For instance, the JSON Web Token (JWT) specification enables claims to be
> communicated that are signed and/or encrypted or that carry no integrity
> protection. Whether integrity protection is required is dependent upon the
> application's requirements and the particular usage context. ****
>
> More detail – look at the small device use cases – these are much more
> detailed about what the use is and what the circumstances are.  The more
> detail the easier it is for people to understand what is going on and why
> this is a useful case.****
>
> This also needs to have some support about why the difference between the
> signed and unsigned cases need to have minimal differences in the
> representation.  Otherwise using an unsigned data structure that is
> specific to that purpose would be a highly justifiable way to go with this.
> ****
>
>  ****
>
> Jim****
>
>  ****
>
>  ****
>
> F8****
>
> Define a format allowing content without integrity protection to be
> represented. ****
>
>  ****
>
>  ****
>
> Richard, I also commented out the reference to RFC 5083, which wasn’t
> being used in the document.  Finally, I updated the document history
> section, including adding the entries for the -04 edits, which had been
> omitted.****
>
>  ****
>
>                                                                 -- Mike***
> *
>
>  ****
>
>  ****
>
> ** **
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Sep 2013 15:09:19 -0700

Given how the model of OAUTH is working as described in the document.  I
cannot see a way that unsigned/unencrypted statements could possibly be a
good idea.  This needs significant expansion.

From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, September 03, 2013 11:24 AM
To: Richard Barnes; Jim Schaad
Cc: [email-masked]
Subject: RE: [jose] Update to Use Cases document for content without
integrity protection

Thanks for writing this Richard.  I believe it's most of the way there.
I've corrected one problem your proposed prose in the attached version,
which is a lightly edited version of your text.  The problem was that you
made it sound like Plaintext JWSs were somehow specific to OpenID Connect,
whereas they're actually already also used in contexts that are not OpenID
Connect.

Protection">

        <t>

                  In some contexts, such as for JSON Web Tokens (JWTs),
there is one more requirement in 

protected content.  Under

                  some circumstances, the recipient of a payload may choose
to 

For example,

                  if the payload is delivered over a TLS-protected channel,
the recipient

                  may regard the protections provided by TLS as sufficient,
so 

optional.

optionally signed

                  and a forthcoming OAuth authentication specification uses
this capability as well. 

        </t>

        <t>

some 

encrypted 

                  object, these metadata values could be carried in a header
with 

would thus

                  there could be a JOSE object representation that does not
apply cryptographic

attached to the

        </t>

      </section>

                                                                Thanks,

                                                                -- Mike

P.S.  The attached source also updates the history section both for -05 and
for the -04 edits.

From: Richard Barnes [mailto:[email-masked]] 
Sent: Friday, August 30, 2013 11:57 AM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Update to Use Cases document for content without
integrity protection

"""

        <t>

example,

        </t>

        <t>

the

        </t>

"""

On Thu, Aug 29, 2013 at 8:04 PM, Jim Schaad <[email-masked]> wrote:

Not ready for prime time

Under some circumstances,  <If you say under some circumstances then those
circumstances need to be clearly delineated>Itit is can be useful to be able
to represent carry content without integrity protection but with in a way
that the same kinds of information about the content that would accompanies
integrity protected content can still accompany the non-integrity-protected
content. The This information about the content, such as the content type
value or application-specification information, is carried as header
parameter values. The capability to represent non-integrity-protected
content is particularly useful in situations when signing the content may be
optional.

<I think given the current way you are trying to get things done, you need
to have a justification for the signed and unsigned versions of the message
being very similar in nature - otherwise it makes more sense to use the
Richard solution of having a different structure for non-integrity protected
objects.> 

For instance, the The JSON Web Token (JWT) specification enables permits
claims to be communicated created that are signed and/or encrypted or that
carry no integrity protection. Whether integrity protection is required is
dependent upon the application's requirements and the particular usage
context. For instance, if If the token content is being communicated over a
channel protected with TLS, the application <A description of this
application would be useful.  Presumably it needs to be a straight
client-server model with no proxies in the middle.>  may be willing to can
accept unsigned content based upon a trust decision utilizing a check of the
sender's TLS certificate; whereas if the content is being sent over a
non-TLS channel, the application may require that the content be signed
and/or encrypted. OpenID Connect has two circumstances <What are these
circumstances?  Are these cases which should be outlined so that we can see
what is happening and why this would be secure?> in which content is
optionally signed and a forthcoming OAuth authentication specification uses
this capability as well<How does it use this capability?  This would be
especially problematic as needing a description given that the OAuth
description above would require that the integrity be in existence since the
token is transmitted via two untrustworthy parties.>. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Monday, August 26, 2013 1:22 PM

To: Richard Barnes
Cc: [email-masked]

Subject: Re: [jose] Update to Use Cases document for content without
integrity protection

The attached versions address these comments - describing a way that
applications can know whether integrity protection is needed, describing
conveying additional information about the content in header parameters, and
listing two different applications using this capability.  Please revise the
Use Cases draft accordingly or reply with specific requests requesting
further revisions before the document is updated.

                                                            Thanks,

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, August 21, 2013 9:37 PM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] Update to Use Cases document for content without
integrity protection

Also: Elaborating on what in the scenario tells the application that it's OK
to get "none" from one recipient and not another.

As to whether this is OpenID: Where else is "alg":"none" currently used?
Better to describe a specific use case.

On Wed, Aug 21, 2013 at 7:43 PM, Jim Schaad <[email-masked]> wrote:

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, August 21, 2013 4:14 PM
To: Jim Schaad; 'Richard Barnes'
Cc: [email-masked]
Subject: RE: [jose] Update to Use Cases document for content without
integrity protection

What additional information would you like to see be included about the use
case?  For instance, would you like the examples about header parameter
values being included with unsigned content that John mentioned on the call?

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Schaad
Sent: Wednesday, August 21, 2013 4:11 PM
To: Mike Jones; 'Richard Barnes'
Cc: [email-masked]
Subject: Re: [jose] Update to Use Cases document for content without
integrity protection

Mike,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Wednesday, August 21, 2013 12:00 PM
To: Richard Barnes
Cc: [email-masked]
Subject: [jose] Update to Use Cases document for content without integrity
protection

Per the decision on the call yesterday that we should define a format for
representing content without integrity protection, and my action item to
produce Use Cases text reflecting this, my proposed text is enclosed.
Richard, I've enclosed edits to -04 that accomplish this.

Under some circumstances is not very specific.  This is probably not how you
want to start this.  You should start this with a more specific case where
this is going to be useful.

content without integrity protection in a way that the same kinds of
information about the content that would accompany

This is a bit problematic with the original version of how JOSE was
specified, but is now ok.  However detail on what types of information are
going to be useful really needs to be stated.

integrity protected content can still accompany the non-integrity-protected
content. This is particularly true when signing the content may be optional.

This is a security document, it should be more detailed about why it should
be optional.

For instance, the JSON Web Token (JWT) specification enables claims to be
communicated that are signed and/or encrypted or that carry no integrity
protection. Whether integrity protection is required is dependent upon the
application's requirements and the particular usage context. 

More detail - look at the small device use cases - these are much more
detailed about what the use is and what the circumstances are.  The more
detail the easier it is for people to understand what is going on and why
this is a useful case.

This also needs to have some support about why the difference between the
signed and unsigned cases need to have minimal differences in the
representation.  Otherwise using an unsigned data structure that is specific
to that purpose would be a highly justifiable way to go with this.

Jim

F8

represented. 

Richard, I also commented out the reference to RFC 5083, which wasn't being
used in the document.  Finally, I updated the document history section,
including adding the entries for the -04 edits, which had been omitted.

                                                                -- Mike