No exactly the topic but also related to this grant type
There is currently no parameter the client could use to explicitly request a
refresh token. So server-policies based on user, client and scope are the only
mean to decide whether a refresh token is issued or not. I consider this to
Issuing a refresh token is more a function of the access grant duration than
anything else. The client can always throw away tokens when it is done of if
the user doesn't want to stay connected, but issuing long term credentials is
not really something the client asks but the server decides
Issuing a refresh token is more a function of the access grant duration than
anything else.
Agreed. How shall the user influence this duration? There is no direct
interaction between authz server and end-user.
The client can always throw away tokens when it is done of if the user doesn't
want
This debate has been going on for 3 years. In OAuth 1.0 it was called token
attributes. Someone just need to write a proposal. Last time I tried, no one
wanted to implement any such mechanism.
EHL
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Thursday, June 30, 2011 6:38
What is the current recommended practice of storing an implicit client's
access_tokens? LocalStorage, im mem and re-request auth on every browser
refresh?
-Doug Tangren
http://lessis.me
___
OAuth mailing list
OAuth@ietf.org
Chuck Mortimore wrote:
A number of us in the community have been working on a general model
for the use of Assertions in OAuth2 for both client authentication, as well
as authorization grants. We’ve reached general consensus on a doc
that I’ve published as a draft
This document is intended
On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba barryle...@computer.org wrote:
This document is intended to replace the SAML and Bearer Token
documents, and those two will then be profiles, defining specific
assertion mechanisms.
Just a couple points of clarification
This doc is not related to
+1 on submitting this as a WG doc by the deadline on July 4th.
As background, http://www.ietf.org/meeting/cutoff-dates-2011.html:
. 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00)
submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool.
.
+1 from me as well on submitting this as a WG doc. And thanks, Mike,
for clarifying the dates.
On Thu, Jun 30, 2011 at 3:31 PM, Mike Jones michael.jo...@microsoft.com wrote:
+1 on submitting this as a WG doc by the deadline on July 4th.
As background,
Just a couple points of clarification
Yes, thanks, Brian, for correcting the stuff I mischaracterized, in
writing my note too quickly.
Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
What is the current recommended practice of storing an implicit client's
access_tokens? LocalStorage, im mem and re-request auth on every browser
refresh?
-Doug Tangren
http://lessis.me
___
OAuth mailing list
OAuth@ietf.org
11 matches
Mail list logo
