[Openid-specs-fapi] Grant Management Draft

[Torsten Lodderstedt]

Hi Vladimir,

thanks for your feedback. Sorry for the delay, but I would like to come back to some of the topics you raised.

> On 27. Mar 2020, at 10:17, Vladimir Dzhuvinov via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> 
> 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 :)

How would you envision deletion of individual scope or claims values? Since there is no identifier associated with them, I would assume the deletion would need to identify the sub element by value, something like a POST request with parameter scope_to_be_removed=read.

What use cases for revocation of individual parts of the grant do you have in mind? I’m asking since the replace mode already offers the capability to remove (all) scopes from a grant and set up the grant with the desired scopes again. Wouldn’t that be sufficient? 

> 
> Grant life cycle: Are grants / grant_id's allowed to expire or their number get limited for a given client_id and user?

Good question. I think an unused grant should expire after some time. I also think there will be expirations for individual elements (e.g. read access to my accounts for 2 weeks), authorisation_details could carry such an expiration in a dedicated field.

> If yes, in what relation to linked refresh and access tokens?

I would like to leave this decision to the AS. I can think of different behaviours:
- tokens stay valid but the permission is adapted - this works best with handle-based tokens
- tokens are invalidated with such a change - this might be the better solution for self contained 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 ...)


We will add it.

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

Interesting question. I think it is possible since the grant_id is present in the authorization request. To be fully stateless, you would also need to implement stateless refresh tokens. I would assume replication could become a nightmare. I would also assume you would need to somehow distinguish old and new versions of grants in case of update & replace mode (which in turn could be handled as revocation of older revisions).

Do you think it’s worth the complexity?  

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

Will add text.

> 
> Excellent consideration of the privacy implications!

Thanks a lot. And thanks again for your feedback. 

best regards,
Torsten. 

> 
> Vladimir
> 
> -- 
> Vladimir Dzhuvinov
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi