this once."
*From:* Torsten Lodderstedt [tors...@lodderstedt.net]
*Sent:* Tuesday, January 17, 2012 12:26 PM
*To:* Paul Madsen
*Cc:* oauth-boun...@ietf.org; Richer, Justin P.; OAuth WG
*Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without
expir
tedt [tors...@lodderstedt.net]
*Sent:* Tuesday, January 17, 2012 12:26 PM
*To:* Paul Madsen
*Cc:* oauth-boun...@ietf.org; Richer, Justin P.; OAuth WG
*Subject:* Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in
Hi Paul,
that's not what I meant. The Client should know which tokens shou
Madsen
Cc: oauth-boun...@ietf.org; Richer, Justin P.; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in
Hi Paul,
that's not what I meant. The Client should know which tokens should be one time
usage based on the API description. The authz server must not re
; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in
Hi Paul,
that's not what I meant. The Client should know which tokens should be one time
usage based on the API description. The authz server must not return expires_in
because this would not make any sen
To: William Mills
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
scope sometimes feels like SAML authncontext - anything can go in there :-)
as I said to Torsten, perhaps an extension is overkill. Just looking for a best
practice
On 1/17/12 12:00 PM, William Mills
2:26 PM
To: Paul Madsen
Cc: oauth-boun...@ietf.org; Richer, Justin P.; OAuth WG
Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in
Hi Paul,
that's not what I meant. The Client should know which tokens should be one time
usage based on the API description. The authz
.
*From:* Paul Madsen
*To:* "Richer, Justin P."
*Cc:* OAuth WG
*Sent:* Tuesday, January 17, 2012 5:23 AM
*Subject:* Re: [OAUTH-WG] Access Token Response without expires_in
Separate from the question posed here, we
al Message-
From: Paul Madsen
Sender:oauth-boun...@ietf.org
Date: Tue, 17 Jan 2012 08:23:37
To: Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
___
OAuth mailing list
OAut
on specify? regards, Torsten. Gesendet
mit BlackBerry® Webmail von Telekom Deutschland -Original Message-
From: Paul Madsen Sender: oauth-boun...@ietf.org Date:
Tue, 17 Jan 2012 08:23:37 To: Richer, Justin P. Cc: OAuth
WG Subject: Re: [OAUTH-WG] Access Token Response without
anuary 17, 2012 12:00 PM
To: Paul Madsen; Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
Does this require an extension? That seems something easy to overload on scope.
From: Paul Madsen
To: "Richer, Just
Does this require an extension? That seems something easy to overload on scope.
From: Paul Madsen
To: "Richer, Justin P."
Cc: OAuth WG
Sent: Tuesday, January 17, 2012 5:23 AM
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
Jones
To: Eran Hammer ; Aaron Parecki ; OAuth
WG
Cc: wolter.eldering
Sent: Tuesday, January 17, 2012 12:54 AM
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
Your new wording is better, as it doesn’t conflict with the possibility of the
expiration time bei
What would such an extension specify?
regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Paul Madsen
Sender: oauth-boun...@ietf.org
Date: Tue, 17 Jan 2012 08:23:37
To: Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Access Token Res
AM
To: Mike Jones
Cc: wolter.eldering; OAuth WG
Subject: Re: [OAUTH-WG] Access Token Response without expires_in
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 encryp
Separate from the question posed here, we are seeing customer demand for
one-time semantics, but agree with Justin that this would best belong in
a dedicated extension parameter and not the default
paul
On 1/16/12 10:29 PM, Richer, Justin P. wrote:
I think #3.
#1 will be a common instance, a
-- 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 a
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
: 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
WG] Access Token Response without expires_in
WFM.
From: Aaron Parecki
[mailto:aa...@parecki.com]<mailto:[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 expi
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 expir
day, 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
anging expires_in from OPTIONAL to RECOMMENDED?
EHL
> -Original Message-
> From: Richer, Justin P. [mailto:jric...@mitre.org<mailto:jric...@mitre.org>]
> Sent: Monday, January 16, 2012 7:29 PM
> To: Eran Hammer
> Cc: OAuth WG; wolter.eldering
> Subject: Re: [OAUTH-WG]
> -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
> >
> >
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] Acc
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 w
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. The
authorization server SHOULD
26 matches
Mail list logo
