<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>My review of the current version in the repo:</p>
    <p>The spec has progressed well since I saw in the slides in London
      and seems pretty workable to me already.</p>
    <p>Back then I stated there is value in enabling fine-grained
      revocation of individual scope values and OIDC claims.
      Incidentally I was discussing a use case that same week which can
      benefit from this. I see there is now a ticket #284 to address
      this. I hope the perceived difficulty in devising a nice mgmt API
      for this won't put you off this :)<br>
    </p>
    <p>Grant life cycle: Are grants / grant_id's allowed to expire or
      their number get limited for a given client_id and user? If yes,
      in what relation to linked refresh and access tokens?<br>
    </p>
    <p>A separate section "The grant life cycle" could potentially be of
      great help.</p>
    <p>For example:<br>
    </p>
    <ul>
      <li>A grant is created in response to: ...</li>
      <li>A grant can be modified by: ...</li>
      <li>A grant can be revoked by: ...</li>
      <li>(A grant expires ...)<br>
      </li>
    </ul>
    <p>Is there a design provision for grant_ids to potentially encode
      the grant (self-contained grant_id) for a (partially) stateless
      implementation?<br>
    </p>
    <p>Effect of grant changes via authz request or mgmt API on issued
      refresh and access tokens: At present the spec is not explicit on
      this. I think there should be clear guidance what happens to
      existing refresh and access tokens linked to a grant_id when the
      grant changes. Including those situations when the client is
      public or multiple client_id's are linked to a "client". This can
      be useful for AS implementers as well as client developers, so the
      latter know exactly what to expect about the tokens when a grant
      gets modified.<br>
    </p>
    <p>Excellent consideration of the privacy implications!<br>
    </p>
    <p>Vladimir<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Vladimir Dzhuvinov</pre>
  </body>
</html>