-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add optional support for historical status resolution #178
base: main
Are you sure you want to change the base?
Conversation
|
||
To obtain the Status List or Status List Token, the Relying Party MUST send an HTTP GET request to the URI provided in the Referenced Token with the additional query parameter `time` followed by a unix timestamp. The response for a valid request SHOULD contain a status list that was valid for that specified time or an error for the JWT and CWT variants and MUST contain a valid status list or an error for the unsigned option. | ||
|
||
If the Server does not support the additional query parameter, it SHOULD signal that by returning a status code of 501 (Not Implemented), or if the queried time is not supported with a status code of 406 (Not Acceptable). These response MUST be supported for the unsigned option, where the client has not other way of checking when the response was valid. The client MUST verify this for the JWT and CWT variants by checking that the specified timestamp is within `iat` (`6` for CWT) and `exp` (`4` for CWT). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if the SHOULD is a benefit, if implementers cannot rely on it, they SHOULD rather use iat
and exp
Co-authored-by: Paul Bastian <[email protected]>
todo:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the language looks good, thanks for including it.
I will only add that while there may be privacy risks, there are legitimate business cases that require such historical data, such as guaranteeing compliance with financial regulation. In these cases, user privacy is made better by using this specification (as opposed to amore privacy-eroding solution), even if maximal privacy is not achieved. I hope the privacy section can speak to this nuance.
Adds support for historical resolution of status as an optional feature.
Closes #138
Rendered Version: https://drafts.oauth.net/draft-ietf-oauth-status-list/c2bo/historical-resolution/draft-ietf-oauth-status-list.html
I will take another look at the wording / normative text and mark as ready for review when I am done.