Shoot, I thought I had fixed the ordering issue in -06.

Sean: Can we just handle both of these in an RFC Editor note?



On Fri, Dec 27, 2013 at 8:46 PM, Mike Jones <[email protected]>wrote:

>  Hi Richard,
>
>
>
> I’d like to raise two issues with the current draft that I believe should
> be addressed in a quick -07 draft.
>
>
>
> First, the three lists in Section 2 (
> http://tools.ietf.org/html/draft-ietf-jose-use-cases-06#section-2) that
> should have parallel orders do not, which is unnecessarily confusing.  I
> believe that they should all be in the order:
>
>
>
>                1.  Integrity-protected object format
>
>                2.  Confidentiality-protected object format
>
>                3.  A format for expressing keys
>
>
>
> The second parallel list should be in the order:
>
>                “signed object format”
>
>                “encrypted object format”
>
>                “key format”
>
>
>
> The third parallel list should be in the order:
>
>                JWS
>
>                JWE
>
>                JWK
>
>
>
> To fix this, you’ll need to reverse the current order of the first two
> items in the first two lists.  (The third list is already in the correct
> order.)
>
>
>
> Second, I’d sent you a private note a few months ago asking you to update
> the OpenID Connect reference, since the OpenID.Messages spec has been
> replaced with OpenID.Core.  You’d agreed to do this, but it didn’t happen.
> Please replace the OpenID.Messages reference with this:
>
>
>
>       <reference anchor="OpenID.Core">
>
>         <front>
>
>           <title>OpenID Connect Core 1.0</title>
>
>
>
>           <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
>
>             <organization abbrev="NRI">Nomura Research Institute,
> Ltd.</organization>
>
>           </author>
>
>
>
>           <author fullname="John Bradley" initials="J." surname="Bradley">
>
>             <organization abbrev="Ping Identity">Ping
> Identity</organization>
>
>           </author>
>
>
>
>           <author fullname="Michael B. Jones" initials="M.B."
> surname="Jones">
>
>             <organization abbrev="Microsoft">Microsoft</organization>
>
>           </author>
>
>
>
>           <author fullname="Breno de Medeiros" initials="B." surname="de
> Medeiros">
>
>             <organization abbrev="Google">Google</organization>
>
>           </author>
>
>
>
>                  <author fullname="Chuck Mortimore" initials="C."
> surname="Mortimore">
>
>                    <organization
> abbrev="Salesforce">Salesforce</organization>
>
>                  </author>
>
>
>
>           <date day="18" month="December" year="2013"/>
>
>         </front>
>
>
>
>                <format target="
> http://openid.net/specs/openid-connect-core-1_0.html";
>
>                 type="HTML" />
>
>       </reference>
>
>
>
>                                                             Thank you,
>
>                                                             -- Mike
>
>
>
> *From:* jose [mailto:[email protected]] *On Behalf Of *Richard Barnes
> *Sent:* Friday, December 27, 2013 11:23 AM
> *To:* [email protected]
> *Subject:* Re: [jose] I-D Action: draft-ietf-jose-use-cases-06.txt
>
>
>
> This is a very minor update to address some wording changes suggested by
> the IESG.
>
> --Richard
>
>
>
> On Fri, Dec 27, 2013 at 2:21 PM, <[email protected]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Javascript Object Signing and Encryption
> Working Group of the IETF.
>
>         Title           : Use Cases and Requirements for JSON Object
> Signing and Encryption (JOSE)
>         Author          : Richard Barnes
>         Filename        : draft-ietf-jose-use-cases-06.txt
>         Pages           : 26
>         Date            : 2013-12-27
>
> Abstract:
>    Many Internet applications have a need for object-based security
>    mechanisms in addition to security mechanisms at the network layer or
>    transport layer.  For many years, the Cryptographic Message Syntax
>    (CMS) has provided a binary secure object format based on ASN.1.
>    Over time, binary object encodings such as ASN.1 have become less
>    common than text-based encodings, for example JavaScript Object
>    Notation.  This document defines a set of use cases and requirements
>    for a secure object format encoded using JavaScript Object Notation
>    (JSON), drawn from a variety of application security mechanisms
>    currently in development.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-use-cases/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-jose-use-cases-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-use-cases-06
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to