<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>