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

From: Mike Jones <[email-masked]>
Date: Wed, 21 Aug 2013 19:00:02 +0000

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 content without integrity protection in a way that the same kinds of information about the content that would accompany integrity protected content can still accompany the non-integrity-protected content. This is particularly true when signing the content may 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.

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: Wed, 21 Aug 2013 17:30:12 -0400

Could you please be more specific?  Why is it that JOSE needs to define
this format, as opposed to just carrying it in some application-specific
way?  Also, it seems like this should be integrated with the OpenID use
case.

Thanks,
--Richard

On Wed, Aug 21, 2013 at 3:00 PM, Mike Jones <[email-masked]>wrote:

>  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 content
> without integrity protection in a way that the same kinds of information
> about the content that would accompany integrity protected content can
> still accompany the non-integrity-protected content. This is particularly
> true when signing the content may 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. ****
>
> ** **
>
> 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: Mike Jones <[email-masked]>
Date: Wed, 21 Aug 2013 21:51:03 +0000

This isn't specific to OpenID (although it is used by OpenID), so it shouldn't be included there.  It also isn't specific to JWT, although JWT uses it.

JOSE needs to define it so that there is a standard (non-application-specific) means of representing non-integrity-protected JOSE content.  There was an agreement on the call yesterday to do so.  (It was your point 1, in fact.)

                                                            -- Mike

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

Could you please be more specific?  Why is it that JOSE needs to define this format, as opposed to just carrying it in some application-specific way?  Also, it seems like this should be integrated with the OpenID use case.

Thanks,
--Richard

On Wed, Aug 21, 2013 at 3:00 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
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.

F8

                                                                -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Aug 2013 16:10:54 -0700

Mike,

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

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, 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

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: Wed, 21 Aug 2013 16:43:53 -0700

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]] 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,

Jim

F8

 

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Wed, 21 Aug 2013 23:13:37 +0000

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]> [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

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

                                                                -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Aug 2013 00:36:37 -0400

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
> ****
> *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****
>
> ** **
>
> 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.****
>
> information about the content that would accompany****
>
> 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.****
>
> More detail – look at the small device use cases – these are much more
> this is a useful case.****
>
> 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****
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 26 Aug 2013 20:22:20 +0000

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]<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

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Schaad

Mike,

Jim

F8

                                                                -- Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 29 Aug 2013 17:04:00 -0700

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

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

                                                                -- Mike

Mike,

Jim

F8

 

                                                                -- Mike

---

From: Richard Barnes <[email-masked]>
Date: Fri, 30 Aug 2013 14:57:23 -0400

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]> 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.****
>
> 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.> ****
>
> 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]
> The attached versions address these comments – describing a way that
> 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]
> OK to get "none" from one recipient and not another.****
>
> ** **
>
>  Better to describe a specific use case.****
>
> ** **
>
> On Wed, Aug 21, 2013 at 7:43 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> *5.9.  Content without Integrity Protection*****
>