(see http://tools.ietf.org/wg/oauth/charters )
On 1/25/12 1:37 AM, Mike Jones wrote:
> Eran, do I then correctly understand that you've changed your mind on
> the position you took in
> http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html,
> which was: "All I agree with is to limit t
Hi Tim,
thanks again for reviewing the threat model document. We will
incorporate your comments into a new revision of our document.
This work will take some time. So if anyone else wants to review the
document, please wait until we announce availability of the next revision.
regards,
Torst
Thanks, that's a good explanation.
From: Eran Hammer
To: "oauth@ietf.org"
Sent: Wednesday, January 25, 2012 10:12 AM
Subject: [OAUTH-WG] WWW-Authenticate Header (Bearer etc.)
People seems confused about the issue raised by Julian. It is pretty simple.
The
People seems confused about the issue raised by Julian. It is pretty simple.
The HTTP WWW-Authenticate header definition allows each header parameter to
have a quoted string or token value. Token values are very restrictive and not
suitable for scope (no spaces, etc.). Quoted strings allow a wid
What I was +1 to there is that it makes sense to limit the character set, and I
still think limiting the character set is the right thing to do.
I have said before in other threads, and still believe, that all of the
definition for things like scope need to be in the OAuth2 base spec and shou
Eran agreed to move the restriction on production rules into the core spec.
That was what I was agreeing with.
I don't quite understand Eran's new position if he has one.
I am in favour of restricting the input, however it is possible I am missing
something in this long thread.
John B.
On 20
And by 'restrict the encoding' I meant limit the allowed character-set in the
value to remove the need for encoding (but encoding which results in a valid
value - as unnecessary as it may be - is still allowed).
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun.
Didn't change my view. I'm expanding it to say that we should restrict the
encoding but at the same time reuse the exact same syntax as the default
header. It's bad for the web if developers write custom parsers just for Bearer
that will break on any other scheme. For example:
WWW-Authentica
My agreement was, and is, to the *production* rules and not the
*parsing* rules. So long as the former is a proper subset of the latter,
everything is fine. What's happening here is that the spec is being read
-- by experts -- as if it were superceding the latter, and that's not a
good thing.
Bjoern Hoehrmann wrote:
>
> * Mike Jones wrote:
> >Thanks for asking, Martin. That's effectively what the spec does
> >already. It restricts the input values of these parameters to be quoted
>
> the HTTP specification does not give you an interface
> that allows you to tell `x`
* Mike Jones wrote:
>Thanks for asking, Martin. That's effectively what the spec does
>already. It restricts the input values of these parameters to be quoted
>strings containing no backslashes.
Most XML parsers do not tell you, and most XML generators do not allow
you to control, the difference
Mike Jones wrote:
>
> Per the discussion at
>http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html,
> the working group's rationale for supporting quoted-string but
> not token syntax for these parameters, and for requiring that
> backslash ('\') quoting not be used when producing t
Eran, do I then correctly understand that you've changed your mind on the
position you took in
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, which was:
"All I agree with is to limit the scope character-set in the v2 spec to the
subset of ASCII allowed in HTTP header quoted-s
On 2012-01-25 03:14, Bjoern Hoehrmann wrote:
...
+1
> ...
If you want to keep the distinction, you should offer an argument why
this is something individual schemes should regulate (since having the
same rules for all schemes is much simpler).
> ...
Exactly. I've been asking this many times
14 matches
Mail list logo
