Change refresh token langugae that implies id-jags should be long lives #62
Conversation
|
See #57 (comment) I think it should be possible to have an ID-JAG with a lifetime that is longer than an Access Token. Access Token lifetimes are managing performance/scale/security tradeoffs and specific to the Resource AS-RS implementation. ID-JAG can be sender-constrained and also have client authentication. It don't think it needs to have single use processing semantics. The ID-JAG lifetime should serialize an access delegation that meets the attenuation requirements of the IDP policy that could have shared signals/etc with the Resource AS. I don't see an issue with an ID-JAG with a lifetime in hours not minutes for example. I wouldn't expect days. Its not a refresh token. |
| The Resource Authorization Server SHOULD NOT return a Refresh Token when an Identity Assertion JWT Authorization is exchanged for an Access Token per {{Section 5.2 of I-D.ietf-oauth-identity-chaining}}. | ||
|
|
||
| When the access token has expired, clients SHOULD re-submit the original Identity Assertion JWT Authorization Grant to obtain a new Access Token. The ID-JAG replaces the use Refresh Token for the Resource Authorization Server. | ||
| When the access token has expired, clients MAY re-submit the original Identity Assertion JWT Authorization Grant to obtain a new Access Token. The ID-JAG replaces the use Refresh Token for the Resource Authorization Server. |
There was a problem hiding this comment.
nit: typo
The ID-JAG replaces the use
ofRefresh Token for the Resource Authorization Server.
Or alternate rephrasing.
3 participants
Id-jag tokens should be encouraged to be short lived, single use artifacts. This language conflicts with that assumption and implies that id-jags may be longer lived than access tokens. We could optionally remove this paragrah