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

[Mike Jones <[e-mail]>]

FYI, the "in some" words already occur in 5 other places in the document; I don't think these are defects there, and I don't think its use was a defect in my previous version.  But nonetheless, since you objected to that wording in this case, I've reworded the text to avoid that construction.

Also, it's important that we be clear that this use case is not specific to either OAuth or OpenID Connect.  That's why both are listed and why it needs to have its own section title.

The revised text follows, with source and output attached.

      <section anchor="unsigned" title="Content without Integrity Protection">
        <t>
                  OpenID Connect and an OAuth authentication specification both utilize
                  the ability to communicate payloads without requiring integrity protection.
                  In both of these cases, the payloads are JSON Web Tokens (JWTs).
                  In this use case, the recipient of a payload can 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.
        </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 to have
                  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>

                                                                -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Tuesday, September 03, 2013 1:27 PM
To: Mike Jones
Cc: Jim Schaad; [e-mail]
Subject: Re: [jose] Update to Use Cases document for content without integrity protection

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 <[e-mail]<mailto:[e-mail]>> 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
                  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:[e-mail]<mailto:[e-mail]>]
Sent: Friday, August 30, 2013 11:57 AM

To: Jim Schaad
Cc: Mike Jones; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Mike Jones
Sent: Monday, August 26, 2013 1:22 PM

To: Richard Barnes
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Wednesday, August 21, 2013 9:37 PM
To: Jim Schaad
Cc: Mike Jones; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
That would be a good start

From: Mike Jones [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, August 21, 2013 4:14 PM
To: Jim Schaad; 'Richard Barnes'
Cc: [e-mail]<mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Jim Schaad
Sent: Wednesday, August 21, 2013 4:11 PM
To: Mike Jones; 'Richard Barnes'
Cc: [e-mail]<mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Wednesday, August 21, 2013 12:00 PM
To: Richard Barnes
Cc: [e-mail]<mailto:[e-mail]>
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