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

["Jim Schaad" <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, September 03, 2013 11:24 AM
To: Richard Barnes; Jim Schaad
Cc: [e-mail]
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.

 

      <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]] 
Sent: Friday, August 30, 2013 11:57 AM
To: Jim Schaad
Cc: Mike Jones; [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]> 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]] On Behalf Of Mike
Jones
Sent: Monday, August 26, 2013 1:22 PM


To: Richard Barnes
Cc: [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]
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]> wrote:

That would be a good start

 

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