Subject: [OAUTH-WG] OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution nitpicking

From: Antonio Sanso <[email-masked]>
Date: Thu, 13 Nov 2014 10:58:57 +0000

hi *.

AFAIU the access token in the  Client-to-AS Response is not “forced” to be JWT format but can also be an opaque string.
Now the example rather says:

HTTP/1.1 200 OK
     Content-Type: application/json
     Cache-Control: no-store

     {
       "access_token":"SlAV32hkKG ...
        (remainder of JWT omitted for brevity;
        JWT contains JWK in the cnf claim)",
       "token_type":"pop",
       "expires_in":3600,
       "refresh_token":"8xLOxBtZp8",
       "key":"eyJhbGciOiJSU0ExXzUi ...
        (remainder of plain JWK omitted for brevity)"
     }
now IMHO this is a bird odd cause 
access_token":"SlAV32hkKG ...
        (remainder of JWT omitted for brevity;
        JWT contains JWK in the cnf claim)
so either is not a JWT and "remainder of JWT omitted… should be removed or SlAV32hkKG should look like a JWT (and it is not the case at the moment :))

regards

antonio

[0] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-00#section-4.2

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Nov 2014 09:05:56 -1000

I think you’re right, the text should probably “remainder of token omitted” for the cases where it’s a non-JWT (and the key is passed from AS to RS in some other fashion) or it should start like a regular JWT in that particular example.

 — Justin

On Nov 13, 2014, at 12:58 AM, Antonio Sanso <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth