good point
William Mills schrieb:
One use tokens can also expire before they are used. "You have 5 minutes to do
this once."
_
From: Torsten Lodderstedt [tors...@lodderstedt.net]
Sent: Tuesday, January 17, 2012 12:26 PM
To: Paul Madsen
Cc: oauth
One use tokens can also expire before they are used. "You have 5 minutes to do
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
S
Scope is a lot closer to authzcontext in concept than authncontext, since OAuth
is out of the authn game.
-- Justin
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of Paul Madsen
[paul.mad...@gmail.com]
Sent: Tuesday, January 17, 2012 12:55 PM
T
By the same argument, the client can know how long the tokens are good for via
API description. What we're talking about is a programmatic hint by the AS to
the Client about what the token is good for. One common use is time-limited,
and so provisions for that have been baked in so that everybod
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 wrote:
Does this require an extension? That seems something easy to overload
on scope.
---
thanks Torsten, but by the same logic we could say that each RS should
document the lifetime of tokens it will accept and so the AS need not
send expires_in - why rely on implicit understanding for one-time
tokens when we dont for those that expire based on time?
I have no particular axe-
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 sense in this case.
regards,
Torsten
Paul Madsen schrieb:
Hi Torsten, yes the use case i
It's a hint to the client so that well-behaved clients don't need to fail with
a limited use token to know that it's probably bad. It lets you throw it away
and re-auth early.
-- Justin
From: William Mills [wmi...@yahoo-inc.com]
Sent: Tuesday, January 17, 2012
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
Separate from
"expires_in" is always a hint to the client about when it might expect to need
to renew the token. It's never authoritative, so it never conflicts with an
expiry time in the token or any other actual mechanism to expire the token.
From: Mike Jones
To: Eran H
Hi Torsten, yes the use case in question is payment-based as well.
Your suggestion for the client to infer one-time usage from a missing
expires_in contradicts the general consensus of this thread does it not?
paul
On 1/17/12 11:38 AM, tors...@lodderstedt.net wrote:
Hi,
isn't one-time seman
Information inside the token is outside of OAuth completely, so I like Eran's
suggestion that doesn't mention how this information would be communicated.
However, I would like to leave it open for different expiration semantics
beyond expiration time. I suggest the following text (which could pr
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
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
con
Andre
Please feel free to propose text, perhaps with a better title than I
suggested. During our discussion on section 4.1.4 (End-user credentials
phished using compromised or embedded browser), we have decided on the
countermeasure below, albeit for a different threat - phishing client as
oppose
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 Par
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
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 e
18 matches
Mail list logo
