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

[Justin Richer <[e-mail]>]

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 <[e-mail]> wrote:

> 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
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth