[Jose-reg-review] Review requested: draft-ietf-stir-passport

Robert Sparks <rjsparks@nostrum.com> Tue, 18 October 2016 18:50 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: jose-reg-review@ietfa.amsl.com
Delivered-To: jose-reg-review@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A8D091296FD for <jose-reg-review@ietfa.amsl.com>; Tue, 18 Oct 2016 11:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.33
X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IcXHmS9JhhKT for <jose-reg-review@ietfa.amsl.com>; Tue, 18 Oct 2016 11:50:45 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D911296CE for <jose-reg-review@ietf.org>; Tue, 18 Oct 2016 11:50:45 -0700 (PDT)
Received: from unnumerable.local ([]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9IIocqD098466 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 18 Oct 2016 13:50:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [] claimed to be unnumerable.local
To: jose-reg-review@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <74d2dbc3-7de7-bb4f-5e9f-5152f76dfd10@nostrum.com>
Date: Tue, 18 Oct 2016 13:50:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------6939945DD98EAD205E267841"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose-reg-review/NuMPeVLUWnOz3E28CKAgoHtYydc>
Cc: "chris_wendt@cable.comcast.com" <chris_wendt@cable.comcast.com>, Russ Housley <housley@vigilsec.com>, Alissa Cooper <alissa@cooperw.in>, Jon Peterson <jon.peterson@gmail.com>
Subject: [Jose-reg-review] Review requested: draft-ietf-stir-passport
X-BeenThere: jose-reg-review@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The JSON Web Algorithm standard \(RFC 7518\) establishes this email list for designated experts to discuss proposed changes, additions, and removals to the set of algorithms in the JSON Object Signing and Encryption \(JOSE\) registry, http://www.iana.org/assignments/jose." <jose-reg-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose-reg-review>, <mailto:jose-reg-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose-reg-review/>
List-Post: <mailto:jose-reg-review@ietf.org>
List-Help: <mailto:jose-reg-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose-reg-review>, <mailto:jose-reg-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 18:50:49 -0000

Please review the registration request in section 11.3 ( key elements 
copied below for convenience) at


Robert Sparks - STIR WG co-chair


11.3. JSON Web Signature and Encryption Header Parameter Registry

11.3.1. Registry Contents Additions Requested

    Header Parameter Name: "ppt"

    o  Header Parameter Description: PASSporT extension identifier

    o  Header Parameter Usage Location(s): JWS

    o  Change Controller: IESG

    o  Specification Document(s): Section 8.1 of [RFCThis]


8.1. "ppt" (PASSporT) header parameter

    Any using protocol can extend the payload of PASSporT with additional
    JWT claims.  JWT claims are managed by an existing IANA registry as
    defined in [RFC7519] Section 10.1.  Implementations of PASSporT MUST
    support the baseline claims defined in Section 5.2, and MAY support
    extended claims.  If it is necessary for an extension to PASSporT to
    require that a relying party support a particular extended claim or
    set of claims in the PASSporT object, it can do so by specifying a
    "ppt" element for the PASSporT JOSE header.  All values of "ppt" need
    to be defined in a specification which associates the new value of
    the "ppt" element with the required claims and behaviors.  Relying
    parties MUST fail to validate PASSporT objects containing an
    unsupported "ppt".

    Using protocols MUST explicitly define the how each claim is carried
    in the using protocol and the rules for how the header and payload
    objects are constructed beyond the lexicographical and serialization
    rules defined in this document.

    Using protocols that carry the compact form of PASSporT, defined in
    Section 7, instead of the full form MUST use only mandatory
    extensions signaled with "ppt" - if a using protocol were to add
    additional optional claims to a PASSporT object it carried in compact
    form, relying parties would have no way to reconstruct the token.
    Moreover, using protocols that support the compact form of PASSporT
    MUST have some field to signal "ppt" to relying parties, as the
    compact form of PASSporT omits the JOSE header.