Tuesday, June 12, 2012 11:57 AM
>Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF
>definitions
>
>
>
>Encoding is an option which does not require us to address it. Those seeking
>to use URIs can simply specify that.
>
>However, Julian indicated e
Reschke; oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
definitions
I agree that there is value in allowing the client_id to be a URI. The problem
is that the ':' of the URI is not allowed in HTTP Basic which is required by
the OAuth2 spec for
h-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
definiti
.@ietf.org] *On
Behalf Of *Mike Jones
*Sent:* Tuesday, June 12, 2012 11:27 AM
*To:* William Mills; Hannes Tschofenig; Julian Reschke
*Cc:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Discussion needed on username and password
ABNF definitions
Not internationalizing fields intended for machine cons
AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
definitions
Not internationalizing fields intended for machine consumption only is already
a precedent set and agreed to by the working group, so let me s
;>
Cc: "oauth@ietf.org<mailto:oauth@ietf.org>"
mailto:oauth@ietf.org>>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
definitions
I had a chat with Julian yesterday and here is my short summary.
Section 2.3 o
ntation layer that's presenting a pretty name for the client_id.
-bill
>
> From: Hannes Tschofenig
>To: Julian Reschke
>Cc: "oauth@ietf.org"
>Sent: Tuesday, June 12, 2012 11:01 AM
>Subject: Re: [OAUTH-WG] Discussion needed on user
I had a chat with Julian yesterday and here is my short summary.
Section 2.3 of the core draft defines client authentication based on two
mechanisms (and provides room for extensions):
http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3
1) HTTP Basic Authentication
2) A custom OAuth
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Mike Jones
> Sent: Tuesday, June 12, 2012 6:17 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
> definitions
>
On 2012-06-12 00:16, Mike Jones wrote:
Reviewing the feedback from Julian, John, and James, I'm coming to the
conclusion that client_id and client_secret, being for machines and not humans,
should be ASCII, whereas username and password should be Unicode, since they
are for humans. Per John's
better ABNF for UNICODENOCTRLCHAR than "", please send it to me!
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Monday, June 11, 2012 8:37 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and passwo
Are we so sure the non-english "half" of the world only use ASCII characters in
passwords? Sounds highly unlikely to me.
> Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest"...
It can work. It is just underspecified. So things can get messy.
draft-reschke-basicauth-enc-05 i
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
rks, which had previously
puzzled me. ;-)
-Original Message-
From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Sunday, June 10, 2012 12:07 PM
To: Mike Jones
Cc: Julian Reschke; oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
definitions
Isn'
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
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 when encoded according to the rules of
RF
21 matches
Mail list logo
