I am OK with that. The expiration time in the token is intended for the protected resource. The client inspecting the token is a potential optimization in cases where the JWT is not encrypted to the protected resource.
I think leaving it open to inspect the token or otherwise provide it in configuration information is flexible enough. John B. On 2012-01-17, at 5:54 AM, Mike Jones wrote: > Your new wording is better, as it doesn’t conflict with the possibility of > the expiration time being in the token. > > -- Mike > > From: Eran Hammer [mailto:e...@hueniverse.com] > Sent: Tuesday, January 17, 2012 12:30 AM > To: Mike Jones; Aaron Parecki; OAuth WG > Cc: wolter.eldering > Subject: RE: [OAUTH-WG] Access Token Response without expires_in > > This is clearly not a solution as actual implementation feedback raised this > issue. We have to document the meaning of this parameter missing. Also, the > example of a self-contained token does not conflict with also providing this > information via the parameter whenever possible to improve interop. > > I’m going to go with adding: If omitted, the authorization server SHOULD > provide the expiration time via other means or document the default value. > > EHL > > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Tuesday, January 17, 2012 12:02 AM > To: Eran Hammer; Aaron Parecki; OAuth WG > Cc: wolter.eldering > Subject: RE: [OAUTH-WG] Access Token Response without expires_in > > This doesn’t work for me, as it doesn’t mesh well with the case of the token > containing the expiration time. For instance, both SAML and JWT tokens can > contain expiration times. In this case, the expires_in time is unnecessary > and the token may have no default expiration time and will expire even though > not explicitly invoked. > > I would recommend no change to the current text, which is: > expires_in > OPTIONAL. The lifetime in seconds of the access token. For > example, the value "3600" denotes that the access token will > expire in one hour from the time the response was generated. > > -- Mike > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Eran Hammer > Sent: Monday, January 16, 2012 11:20 PM > To: Aaron Parecki; OAuth WG > Cc: wolter.eldering > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > WFM. > > From: Aaron Parecki [mailto:aa...@parecki.com] > Sent: Monday, January 16, 2012 11:08 PM > To: OAuth WG > Cc: Eran Hammer; Richer, Justin P.; wolter.eldering > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > Actually now I'm having second thoughts about making expires_in RECOMMENDED. > Here's another attempt at a clarification: > > expires_in > OPTIONAL. The lifetime in seconds of the access token. For > example, the value "3600" denotes that the access token will > expire in one hour from the time the response was generated. > If omitted, the authorization server SHOULD document the > default expiration time or indicate that the token will not > expire until explicitly revoked. > > -aaronpk > > > On Mon, Jan 16, 2012 at 10:37 PM, Eran Hammer <e...@hueniverse.com> wrote: > Hmm. This might become too much work at this stage… > > Happy for suggestions but I won’t pursue it on my own for now. > > EHL > > From: Aaron Parecki [mailto:aa...@parecki.com] > Sent: Monday, January 16, 2012 10:36 PM > To: OAuth WG > Cc: Richer, Justin P.; wolter.eldering; Eran Hammer > > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > That seems like a good idea, but then it should also be explicitly stated > what to do if the server issues non-expiring tokens. > > aaronpk > > > On Mon, Jan 16, 2012 at 10:29 PM, Eran Hammer <e...@hueniverse.com> wrote: > How do you feel about changing expires_in from OPTIONAL to RECOMMENDED? > > EHL > > > -----Original Message----- > > From: Richer, Justin P. [mailto:jric...@mitre.org] > > Sent: Monday, January 16, 2012 7:29 PM > > To: Eran Hammer > > Cc: OAuth WG; wolter.eldering > > Subject: Re: [OAUTH-WG] Access Token Response without expires_in > > > > I think #3. > > > > #1 will be a common instance, and #2 (or its variant, a limited number of > > uses) is a different expiration pattern than time that would want to have > > its > > own expiration parameter name. I haven't seen enough concrete use of this > > pattern to warrant its own extension though. > > > > Which is why I vote #3 - it's a configuration issue. Perhaps we should > > rather > > say that the AS "SHOULD document the token behavior in the absence of this > > parameter, which may include the token not expiring until explicitly > > revoked, > > expiring after a set number of uses, or other expiration behavior." That's > > a lot > > of words here though. > > > > -- Justin > > > > On Jan 16, 2012, at 1:53 PM, Eran Hammer wrote: > > > > > A question came up about the access token expiration when expires_in is > > not included in the response. This should probably be made clearer in the > > spec. The three options are: > > > > > > 1. Does not expire (but can be revoked) 2. Single use token 3. > > > Defaults to whatever the authorization server decides and until > > > revoked > > > > > > #3 is the assumed answer given the WG history. I'll note that in the spec, > > but wanted to make sure this is the explicit WG consensus. > > > > > > EHL > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
