[Openid-specs-fapi] Grant Management Draft

[Vladimir Dzhuvinov]

My review of the current version in the repo:

The spec has progressed well since I saw in the slides in London and
seems pretty workable to me already.

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

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?

A separate section "The grant life cycle" could potentially be of great
help.

For example:

  * A grant is created in response to: ...
  * A grant can be modified by: ...
  * A grant can be revoked by: ...
  * (A grant expires ...)

Is there a design provision for grant_ids to potentially encode the
grant (self-contained grant_id) for a (partially) stateless implementation?

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.

Excellent consideration of the privacy implications!

Vladimir

-- 
Vladimir Dzhuvinov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200327/c91808c3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200327/c91808c3/attachment.p7s>