[Openid-specs-fapi] FAPI Slide Deck

[Vladimir Dzhuvinov]

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.

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. And I'm not sure whether
touching its immutability would be a good thing at all.

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

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.

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


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


-------------- 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/20200213/a43b55e8/attachment.p7s>