[Openid-specs-fapi] FAPI Slide Deck

[Torsten Lodderstedt]

> On 13. Feb 2020, at 10:11, Vladimir Dzhuvinov <vladimir at connect2id.com> wrote:
> 
> On 12/02/2020 22:11, Torsten Lodderstedt wrote:
>> Hi Vladimir,
>> 
>>> On 12. Feb 2020, at 19:51, Vladimir Dzhuvinov via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>>> 
>>> Hi Torsten,
>>> 
>>> How does the lifecycle of the grant resource exposed at the
>>> /grants/{grant_id} endpoint tie to the lifecycle of the issued access /
>>> refresh token?
>>> 
>>> Does it expire with the access token if no refresh token is issued?
>> Excellent question! Basically, it is supposed to work the other way around. 
>> 
>> The grant_id is an external representation of the grant underlying any token. 
>> 
>> If a grant is revoked, it effectively makes the token useless, since the underlying grant is gone. 
>> 
>> If an access token is revoked or expires, this only means the credential created based on a certain grant is no longer usable. But the grant still exists.
>> 
>> Same if a refresh token is revoked or expires. The client can at any time re-acquire tokens for that grant by going through an authorization process again. If there is a grant for a given client_id/user_id combination, it will be used to inform this authorisation process. If the grant already fulfils the scopes/authorization details the client is requesting, there is not even a need for acquiring user consent (again). 
>> 
>> Does this make sense for you? I think connect2id’s subject session is very similar to the concept of a grant.
> 
> I see. So the ``grant_id'' mechanism essentially allows the grant to
> live happily as an independent resource, referenced by a unique ID. It
> remains unaffected when the credentials (tokens) linking to it expire or
> get invalidated (revoked). To conserve AS resources it might be prudent
> to have some reasonable expiration of grant resources though.

I agree. 

> 
> Yesterday a customer talked to me, explaining that for some kind of new
> mobile application, they want to be able to invalidate the refresh token
> while keeping the previously given consent intact. Mostly to make the UX
> smoother and more sensible from the perspective of their particular
> application and how it works. They have considered implementing this
> with a non-standard API call to the AS. I now see this ``grant_id''
> could well be a cleaner way to achieve the same thing. The snag is that
> they may need to revoke some of the scope values from the consent as
> well (UserInfo offline_access if I'm not mistaken). I don't see how this
> can be done with the ``grant_id'' as suggested.

Good point. One would need to add a function to remove sub-resources. That would be easier with authorization details since the elements in the array could be removed (if somehow identifiable). In a chat with Stuart, Dima and Daniel about consent management, we came across a similar idea. 

> And I'm not sure whether
> touching its immutability would be a good thing at all.

The grant is not supposed to be immutable. The client can at any time increase the scope of a grant by going through another authorisation process and ask for different or more scope values (or authorization details).

> 
> Could I share a screenshot of the ``grant_id'' relevant slides with
> them, to get their thoughts on that?

sure. 

> 
> What I also like about the ``grant_id'' is how clients can get a clear
> record of the exact consents. Because right now with OAuth 2.0 that's
> not exactly possible. The consented scopes may be gleaned from the
> access token response, but not OpenID claims.

You are right, that would be a reasonable feature as well. 

> 
> Given the way how token introspection evolved, I suppose a JWS response
> would also eventually be needed here.

Good point :-)

> 
> 
> Vladimir
> 
> 
> 
>> best regards,
>> Torsten. 
>> 
>>> Vladimir
>>> 
>>> On 29/01/2020 16:49, Torsten Lodderstedt via Openid-specs-fapi wrote:
>>>> Hi all, 
>>>> 
>>>> as discussed in the call today, I started to create a slide deck about the next FAPI revision and look for your feedback/contribution. 
>>>> 
>>>> Here is the link: https://docs.google.com/presentation/d/1LyebJ8FhC1sIM9F5e9TNHRPDOYuXiilHt4wQBkvRvtc/edit#slide=id.p
>>>> 
>>>> If you want to access/contribute, please request access (respective screen will be shown by Google Docs).
>>>> 
>>>> best regards,
>>>> Torsten. 
> 
> -- 
> Vladimir Dzhuvinov
> 
>