As for the plus encoding we can choose another char or give an example.
On Jul 11, 2011, at 18:07, "Marius Scurtescu" wrote:
> If I read section 8.4 correctly it seems that new response types can
> be defined but composite values must be registered explicitly.
>
> I don't think this approach s
You are over complicating it. You can define anything you want. But if you want
to use the special + character, each of the parts must be defined and
registered. If parts of a combination don't make sense on their own use
something else to join them like underscore.
EHL
On Jul 11, 2011, at 18
If I read section 8.4 correctly it seems that new response types can
be defined but composite values must be registered explicitly.
I don't think this approach scales too well. OpenID Connect for
example is adding a new response type: id_token.
id_token can be combined with either code or token a
My guess about no cookies was in the design of implicit client token
passing, the access token is never shared with the server, only the browser
via the redirect_uri's fragment. Once the browser has the token, my question
was about how (or even if) people are storing access tokens between page
refr
Can't LocalStorage etc be stolen with XSS too? If an attacker gets
their JS running on the page then the game is up.
Ian
On Mon, Jul 11, 2011 at 7:06 PM, Larry Suto wrote:
> Cookies can be stolen by directed XSS attacks.
>
> Larry
>
> On Mon, Jul 11, 2011 at 3:46 PM, Eran Hammer-Lahav
> wrote:
Cookies can be stolen by directed XSS attacks.
Larry
On Mon, Jul 11, 2011 at 3:46 PM, Eran Hammer-Lahav wrote:
> Any cookie? What about a Secure cookie limited to a specific sub-domain?
> What are the concerns about cookies? I think this would be helpful to
> discuss.
>
> EHL
>
> > -Original
The issue with a cookie is that it might go over the wire in
plain-text. If a cookie is set to be Secure (and hence only used over
HTTPS) then it should be fine.
Ian
On Mon, Jul 11, 2011 at 6:46 PM, Eran Hammer-Lahav wrote:
> Any cookie? What about a Secure cookie limited to a specific sub-domai
Any cookie? What about a Secure cookie limited to a specific sub-domain? What
are the concerns about cookies? I think this would be helpful to discuss.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Marius Scurtescu
> Sent: Monday,
On Thu, Jun 30, 2011 at 12:45 PM, Doug Tangren wrote:
> 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?
Both sound reasonable. I think most important is how NOT to store it,
in a cookie.
For your info. Some of this material may be of interest -- particularly for
those looking at developing token specifications that carry session
information.
While this specification is meant for browser sessions, some of the info may be
relevant to tracking state with http clients via authori
10 matches
Mail list logo
