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
https://www.ietf.org/mailman/l
> 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
+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 wrote:
> +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
+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.
. 2011-0
On Thu, Jun 30, 2011 at 2:39 PM, Barry Leiba 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 the Bearer Token d
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 intende
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
https://www.ietf.org/mailman/l
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 AM
>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
>w
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 (b
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
limit
I've resurfaced from my project launch and will be giving the spec some
attention over the weekend holiday. I've got a long list of changes to make
from the meeting and list. I plan to post a new draft sometimes next week, give
people a week for quick feedback, and based on the issues raised, as
12 matches
Mail list logo
