Oh no... I never even noticed the drama. I thought that everything has
been agreed on...
Igor
On 6/8/2012 5:31 PM, Peter Saint-Andre wrote:
I must say that I found it surprising, too. An explanation beforehand
from the chairs would have helped to prevent confusion.
On 6/8/12 3:28 PM, Eran Ha
BRAVO!
Igor
On 6/8/2012 2:08 PM, Dick Hardt wrote:
On Jun 8, 2012, at 10:51 AM, Mike Jones wrote:
The chairs approved publication of OAuth Core draft -27 today. This
version is based upon the proposed changes that I’d circulated to the
working group. Changes are:
·Adds character set restr
So we have two competing good ideas.
1 include an ABNF directly and codify what is expected to to work at the cost
of flexibility.
2 Reference RFC 2617 itself referencing RFC 2616 to allow for a future fix to
the encoding limitations to be automatically picked up by OAuth if RFC 2617 is
updated
Hi Julian,
As background, the reason for the special ABNF is to satisfy a DISCUSS raised
by Sean Turner specifically that specifically requested a comprehensive ABNF.
I believe that these very discussions show how valuable Sean's request is to
improving the clarity of the spec for implementer'
On 2012-06-10 20:50, Mike Jones wrote:
Thanks for your reply, Julian.
Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", and they're
required to be used with Basic, I believe that that confirms that username and password must either
be ASCII or ISO-8859-1, and given that
I think once the WG decided that client_id and client_secret need to be passed
as the username and password for HTTP Basic authentication of the client to the
Token Endpoint, the Die was cast for those elements to have the same character
restrictions.
In principal you could use the assertion p
2.3.1 of Core http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3.1
requires support for HTTP Basic. Actually, in this context, it's requiring
support for using Basic with client_id and client_secret, therefore I believe
those must be restricted to ASCII, as (per Julian's note), UTF-8
Isn't the nuance that Basic and Digest should be able to be passed through
OAuth? Or is there a secondary requirement that uid/passwords forms in OAuth
be re-encodable to Basic?
So while "UTF-8 may not work with Basic and Digest" is that a valid concern?
I think our concern should be limited
Thanks for your reply, Julian.
Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", and
they're required to be used with Basic, I believe that that confirms that
username and password must either be ASCII or ISO-8859-1, and given that
several people have written that ISO-88
On 2012-06-08 20:09, Mike Jones wrote:
Hi Julian,
The current draft restricts username and password to ASCII was because RFC 2616
says this about the TEXT fields used by HTTP Basic in RFC 2617:
"Words of *TEXT MAY contain characters from character sets other than
ISO-8859-1 [22] only w
About Julian's issue raised at
http://www.ietf.org/mail-archive/web/oauth/current/msg09164.html, please see my
message to him and the working group "[OAUTH-WG] Discussion needed on username
and password ABNF definitions" at
http://www.ietf.org/mail-archive/web/oauth/current/msg09171.html. In i
Hi Franklin,
On Jun 9, 2012, at 7:09 AM, Franklin Tse wrote:
> I think the chairs should clarify and explain, via this mailing list,
>
> 1. Whether they have authorized Mike Jones and Dick Hardt to author and
> publish the draft
Derek and I had asked for a new draft version. We are interested
Hi Eran, Hi all,
The story is fairly simple: We have three authors on draft-ietf-oauth-v2.
Having more than one author is helpful in case others are busy.
We had open issues with the document and we discussed them on the list. Text
was proposed and feedback was provided to the list. Thanks eve
13 matches
Mail list logo
