Subject: [media-types] Review request for application/passport

From: Robert Sparks <[email-masked]>
Date: Tue, 18 Oct 2016 09:39:08 -0500

Please review this request for registering application/passport.

See <https://datatracker.ietf.org/doc/draft-ietf-stir-passport/>

10.1. Media Type Registration

10.1.1. Media Type Registry Contents Additions Requested

    This section registers the "application/passport" media type
    [RFC2046] in the "Media Types" registry in the manner described in
    [RFC6838], which can be used to indicate that the content is a
    PASSporT defined JWT and JWS.

    o  Type name: application

    o  Subtype name: passport

    o  Required parameters: n/a

    o  Optional parameters: n/a

    o  Encoding considerations: 8bit; application/passport values outside
       the US-ASCII range are encoded using percent encoding as described
       in Section 2.1 of [RFC3986] (some values may be the empty string),
       each separated from the next by a single period ('.') character.

    o  Security considerations: See the Security Considerations
       Section of [RFC7515].

    o  Interoperability considerations: n/a

    o  Published specification: [RFCThis]

    o  Applications that use this media type: STIR and other applications
       that require identity related assertion

    o  Fragment identifier considerations: n/a

    o  Additional information:

       Magic number(s): n/a File extension(s): n/a Macintosh file type
       code(s): n/a

    o  Person & email address to contact for further information: Chris
       Wendt, [email-masked]

    o  Intended usage: COMMON

    o  Restrictions on usage: none

    o  Author: Chris Wendt, [email-masked]

    o  Change Controller: IESG

    o  Provisional registration?  No

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Oct 2016 10:49:42 +0100

Hi Robert,

This looks basically fine, a couple of minor things below:

>        each separated from the next by a single period ('.') character.
This looks a bit contradictory: if non US-ASCII values are %-encoded, 
then this will be 7bit?

Also, can you have lines longer than 1000 octets here before CRLF? If 
the answer is yes, then Encoding should be "7bit or Binary" (or "8bit or 
Binary").
>        Magic number(s): n/a File extension(s): n/a Macintosh file type
A nit: I personally prefer a file extension to be registered.
>        Wendt,[email-masked]
>
>     o  Intended usage: COMMON
>
>     o  Author: Chris Wendt,[email-masked]
>

---

From: Mark Baker <[email-masked]>
Date: Wed, 19 Oct 2016 16:22:13 -0400

>    PASSporT defined JWT and JWS.

My concern about the name is its broad nature. Is there a more
specific name that could be used instead?

Also, would a +json suffix be suitable? I see there's a canonical form
defined; is that why the suffix wasn't used?

>       each separated from the next by a single period ('.') character.

In addition to Alexey's comments, I'm not quite sure what's going on
at the end of that description, and I can't find any percent encoded
examples in the draft to help me understand.

Mark.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Oct 2016 15:15:19 +0100

Hi Chris,

A few corrections below:

On 25/10/2016 14:37, Chris Wendt wrote:
> Hi Alexey,
>
> Yes this is a mistake, I changed the body text to align with the 
> unicode rules in JWS, but missed changing this in the media type 
> registration as well.
>
> New text (including change for +json suggested by Mark) will be:
>
> 11.  IANA Considerations
>
> 11.1.  Media Type Registration
>
> 11.1.1.  Media Type Registry Contents Additions Requested
>
>    This section registers the "application/passport+json" media type
>    PASSporT used to assert identity related information in JSON format.
>
>    o  Type name: application
>
>    o  Subtype name: passport
passport+json ?
>    o  Encoding considerations: 8bit; application/passport+json values are
>       represented as a JSON object; UTF-8 encoding SHOULD be employed
>       for the JSON object as defined in [RFC7519] Section 7.
I think you should use "binary" as application/json registration. This 
would be especially needed if some flavour of UTF-16 is used (you are 
only using SHOULD, not a MUST above).

>       Magic number(s): n/a File extension(s): .json
You should register a new file extension.
> Macintosh file type
>       Wendt, [email-masked] <mailto:[email-masked]>
>
>    o  Intended usage: COMMON
>
> <mailto:[email-masked]>
>
>>> Encoding considerations: 8bit; application/passport values outside
>> On Oct 19, 2016, at 4:49 AM, Alexey Melnikov 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Robert,
>>
>> the answer is yes, then Encoding should be "7bit or Binary" (or "8bit 
>> or Binary").

---

From: Chris Wendt <[email-masked]>
Date: Tue, 25 Oct 2016 18:35:01 -0400

Hi Alexey,

Inline

> passport+json ?

Originally this indeed was a mistake, but after some discussion and specifically Jim Schaad pointed out that PASSporT after construction is not a JSON object, but rather a bunch of Base64 encoded characters with ‘.'.  So, based on this I think we should stick with just “passport"

>>       for the JSON object as defined in [RFC7159] Section 7.
> I think you should use "binary" as application/json registration. This would be especially needed if some flavour of UTF-16 is used (you are only using SHOULD, not a MUST above).

Based on conclusion above about only using Base64 encoded ASCII/UTF-8 and some further discussion and looking at JWT/JWS, we are going to change this to 

 o Encoding considerations: 8bit; PASSporT values are encoded as a series
      of base64url-encoded ASCII values (some of which may be the empty
      string) separated by period ('.') characters.

The only thing here we could consider is setting 7bit, because the resulting Base64 and ‘.’ is really just ASCII characters, but didn’t want to conflict with what is in RFC7519 JWT.
   o  Type name: application
   o  Subtype name: jwt
   o  Required parameters: n/a
   o  Optional parameters: n/a
   o  Encoding considerations: 8bit; JWT values are encoded as a series
      of base64url-encoded values (some of which may be the empty
      string) separated by period ('.') characters.

> You should register a new file extension.

So, i’m ok just adding .json as a possible use of storing passport object, but in reality these tokens are only constructed during the life of a call in the real-time signaling path, so we really would NEVER create any file for this, so now I’m thinking we just go back to n/a, if that’s acceptable.

Here is the resulting proposed request:

* Type name: application
* Subtype name: passport
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: 8bit; application/passport values are encoded as a series
      of base64url-encoded values (some of which may be the empty
      string) separated by period ('.') characters..
* Security considerations: See the Security Considerations Section of {{RFC7515}}.
* Interoperability considerations: n/a
* Published specification: [RFCThis]
* Applications that use this media type: STIR and other applications that require identity related assertion
* Fragment identifier considerations: n/a
* Additional information:

     Magic number(s): n/a
     File extension(s): n/a
     Macintosh file type code(s): n/a

* Person & email address to contact for further information: Chris Wendt, [email-masked]
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Chris Wendt, [email-masked]
* Change Controller: IESG
* Provisional registration?  No