Skip to main content

PASSporT: Personal Assertion Token
RFC 8225

Yes

(Alissa Cooper)
(Ben Campbell)

No Objection

Alvaro Retana
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 10 and is now closed.

Alvaro Retana No Objection

(Alissa Cooper; former steering group member) Yes

Yes (for -10)

                            

(Ben Campbell; former steering group member) Yes

Yes (for -10)

                            

(Kathleen Moriarty; former steering group member) Yes

Yes (2016-11-02 for -10)
Thanks for a very well written example of how to use some of the JOSE work.

In section 9.1 there's another nit that was not identified (that I can see) by other reviewers.

This section demonstrate the deterministic JSON 
s/demonstrate/demonstrates/

(Alexey Melnikov; former steering group member) No Objection

No Objection (2016-11-01 for -10)
This is generally a well written and detailed document. Thank you.

I have some minor comments:

5.1.1.  "iat" - Issued At claim

   The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined
   claim Issued At.  As defined the "iat" should be set to the date and
   time of issuance of the JWT and MUST the origination

I think a verb is missing between "MUST" and "the origination"

   of the personal
   communications.

5.2.2.  "mky" - Media Key claim

   2.  Sort the lines based on the UTF8 encoding

UTF-8 needs a normative reference (RFC 3629).

       of the concatenation of
       the "alg" and "dig" claim value strings.

7.1.  Example Compact form PASSporT Token

  eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9

I decoded this and it looks reasonable:
 {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/passport.cer"}

   .
   eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
   6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0

OpenSSL produced the following:

 {"dest":{"uri":["sip:alice@example.com"]},"iat":

this looks like a truncated value. Is something wrong with the value or is this an OpenSSL bug?

(Alia Atlas; former steering group member) No Objection

No Objection (2016-11-02 for -10)
Nit:

In Sec 5.1.1:
"As defined the "iat" should be set to the date and
   time of issuance of the JWT and MUST the origination of the personal
   communications."
I assume that should be "MUST be" ?

(Benoît Claise; former steering group member) No Objection

No Objection (2016-11-01 for -10)
Editorial feedback from Bert Wijnen, our OPS-DIR reviewer:
While I was at it, I found someNits and/or typos:

The abstract states:


                            The PASSporT token is cryptographically
   signed to protect the integrity of the identity the originator and to
   verify the assertion of the identity information at the destination.

s/the identity the originator/the identity of the originator/
Or so I think.

section 5.1.1 states:


                   As defined the "iat" should be set to the date and
   time of issuance of the JWT and MUST the origination of the personal
   communications.  The time value should be of the format defined in
   [RFC7519] Section 2 NumericDate.

Is that a correct sentence? or is the a verb missing around
   "the JWT and MUST the origination" ???

Section 5.2.2

5.2.2. "mky" - Media Key claim Why such a cryptic "mky". Why not "mkey" ?? I can live with it. I just wonder why we make it more cryptic than needed. Section 10.2 2nd bullet        In many applications, the end user represented by the asserted
      identity represents and signer may not be one in the same
I do/did not know the term "one in the same". I do know "one and the same". I guess other people may have the same knowledge as I do (as non native English speaker) Bert

(Deborah Brungard; former steering group member) No Objection

No Objection (for -10)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -10)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -10)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2016-11-01 for -10)
"The claim value for the "tn" claim is the telephone number and MUST
   be canonicalized according to the procedures specified in
   [I-D.ietf-stir-rfc4474bis] Section 8.3."
This indicated that's section 8.3 of ietf-stir-rfc4474bis belongs in this doc. Is there are reason why it is in ietf-stir-rfc4474bis instead?

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -10)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2017-02-12)
Thanks for handling my DISCUSS about deterministic signing.

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -10)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -10)