lifetime of grant_id
Issue #379
resolved
From an implementer's point of view, it is a big point whether the lifetime of grant_id expires or not. If grant_id should not be invalidated even after all access/refresh tokens associated with the grant_id expire, maintaining grant_id records would become a hard task for authorization server implementations. It's because there is no timing for authorization server implementations to delete grant_id records and garbage grant_id records continue to be accumulated endlessly.
Comments (15)
-
-
@Ralph Bragg in my opinion, it is not the job of the AS to maintain legal records of customer consents. When authorization is created via AS, a legal record can be saved elsewhere.
@Takahiko Kawasaki it’s a good point about grant lifecycle. If the above assumption is ok, AS could delete the grant after it becomes inactive (either expired or revoked).
Should the grant have an expiry date? We have started this discussion here: https://bitbucket.org/openid/fapi/issues/355/grant-management-should-grants-expire.
Thoughts?
-
@Dima Postnikov I think where the legal record is stored is really implementers choice and while it may not be in “AS” it may be in a tightly coupled component related to the AS.
@Takahiko Kawasaki I think grant’s should never expire unless there’s a data collection limitation (as @Ralph Bragg pointed out 7 years after last interaction is most common). They definitely should never be reused. For what it’s worth, if a grant has reached it’s end there might be an upper bound on when it is no longer addressable (ie. kind of like the “move to glacier” lifecycle option in S3)?
-
I agree with @Dima Postnikov regarding the legal records. I’ll say even more - providing access to historical data (e.g. grant change history) in an online fashion doesn’t have to be and in many cases won’t be AS job. AS should output proper audit information for any such grant management operation.
In addition to @Takahiko Kawasaki justification, it’s worth to mention that currently as per section “OAuth Protocol Extensions->Authorization Request” logically in case of expiry of all tokens such grant would be orphaned and never used again. That’s unless we assume that a use case exists where client application presents
grant_idof existing grant in the fresh authorization request and such grant is used as a hint to pre-populate items on the consent screen. It doesn’t sound like a compelling use case.
-
If we put legal records aside…
From a grant lifecycle perspective, AS needs to know when it can cleanup existing grant. It can be done based on a status flag (revoked or inactive), expiry or both. Once AS considers the grant inactive, revoked or expired, it cannot be referenced.
For me personally, it makes sense to have an expiry on a grant level. It would be great to get more feedback from the implementors.
-
It essential here to distinguish between expiration of the grant (for validity) and the expiration data of the grant (for cleanup).
Date invalide grants will still have to be kept in a database for reporting purpose. This database can be either the AS database or third data store.
-
@Francis Pouatcha I agree the requirement is still there, we just not prescribing here how it is solved.
@Ralph Bragg @Lukasz Jaromin @Francis Pouatcha @Dave Tonge please review this PR if you have a chance (last part - out of scope is relevant to this discussion).
-
I agree that the AS shouldn’t be responsible for storing past grants for legal purposes.
If grants could have user data and the AS could expose a bulk query endpoint - then keeping them indefinitely would be useful. However currently this is out of scope and therefore there isn’t much point the AS keeping past grants.
-
Suggested wording: Lifecycle of the grant
Authorization server may remove an obsolete grant at its discretion, but it should consider status and expiry of authorization elements included in the grant. The exact mechanism could differ between different deployments, for example, some deployments could purge a grant when all individual authorization_details attached to the grant have expired or revoked.
any commentes?
-
Dave: we need to go through the behaviour of AS on how to deal with expired grants.
-
To cover historical use case, this is what the spec says now:
Use cases not supported
Historical grant, authorisation or consent records
Grant Management specification allows a client to query the status and contents of a grant (user consent). This is designed for clients to understand what is included in current active grant. This is NOT designed to provide for legal, reporting or archiving purposes, for example, keeping 7 years of expired or revoked consents.
-
to review in today’s meeting and close it if no more comments.
-
- changed status to open
-
-
assigned issue to
Dima Postnikov
-
assigned issue to
-
- changed status to resolved
Discussed in todays call - can be closed now.
- Log in to comment
Actually from my point of view this is an area where you’ll find different jurisdictions will have different requirements for the validity and length of these records to persist. For example i would expect these records to be accessed by customers wanting to have a history of their grants for up to 7 years and the same period of access to be expected for the Clients / TPPs. I don’t think we should be putting a minimum or maximum cap on it but i do think that implementors or at least data control / protection officers should expect to need to surface old grants for a very long time especially if the grant is going to be used to share data which is then used to make a credit or insurance risk decision like a mortgage or life insurance product some of which could persist for 30 years!