[Openid-specs-mobile-profile] [Async JWT Profile] draft-oauth-versatile-jwt-profile-03

Manger, James James.H.Manger at team.telstra.com
Wed Apr 5 03:29:08 UTC 2017

§3.3 "Polling Request" says:
  "A Client configured with a "client_notification_endpoint" MUST NOT send a Polling Request."
But this seems unnecessary, and contradicts §2 that says "a given "client_id" can use both mechanisms".
Drop this "MUST NOT" paragraph.

You should be able to move the common parts of §4.3.1 and §4.3.2 into §4.3, instead of repeating them. Particularly that the notification POST MUST be a JSON object, and the presence or absence of an "error" member indicates if it is an error or success response respectively.

It might be nice for §1.3.2 "Asynchronous Poll flow" to show one (or more) unsuccessful polling requests, not just the final one that succeeds.

Add a sentence to §2 "Client registration" (probably), and perhaps even an example metadata value:
  "An OP MUST indicate the asynchronous modes it supports by listing the associated "grant_type" values in the "grant_types_supported" member of the OP's metadata [OpenID.Discovery]"

James Manger

From: nicolas.aillery at orange.com [mailto:nicolas.aillery at orange.com]
Sent: Tuesday, 4 April 2017 6:30 PM

Hello James,

   Thanks for the reviews!
   Here are my comments inline, and a draft v3,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170405/cd919275/attachment.html>

More information about the Openid-specs-mobile-profile mailing list