I am still Ok with -22, but I have 1 new comment raised by introduction
of the base64 ABNF non terminal:
I think it would be worth adding a comment for b64token that points to
the base64 RFC. The current ABNF is too permissive (arbitrary number of
"=" allowed at the end) and there are enough b
Folks. Please don't develop any new revisions for these
documents right now. I know you can't officially post
'em anyway, but I don't want us to get tempted to roll
new versions handling unrelated comments. (Alexey's
comments are not unrelated.)
I'd like to handle any tweaks needed as RFC editor
(Routing this to Kitten WG)
I don't have much of a preference here, on the one hand I think a plaintext
hint is very reasonable, on the other I suspect people will be tempted to use
it for more than that which would be bad. In the HTTP space it's easy for
anyone using OAuth to put a plaintext
FYI, the b64 token definition is identical to the one in
draft-ietf-httpbis-p7-auth-20. If it works there, it should work for OAuth
Bearer.
-- Mike
From: Stephen Farrell
Sent: 7/17/2012 4:12 AM
To: draft-ietf-oauth-v2-bearer@tools.ietf.org
Cc: General Area
On 2012-07-17 18:10, Mike Jones wrote:
FYI, the b64 token definition is identical to the one in
draft-ietf-httpbis-p7-auth-20. If it works there, it should work for
OAuth Bearer.
...
+1; not every constraint needs to be expressed in the ABNF. "b64token"
is here so recipients can parse the hea
On 17/07/2012 17:40, Julian Reschke wrote:
On 2012-07-17 18:10, Mike Jones wrote:
FYI, the b64 token definition is identical to the one in
draft-ietf-httpbis-p7-auth-20. If it works there, it should work for
OAuth Bearer.
...
+1; not every constraint needs to be expressed in the ABNF. "b64tok
For clarity of discussion, the definition in question is:
b64token= 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Note that b64token is a liberal syntax intended to permit base64 encoded
content (hence the inclusion of the "+" and "/" characters and
On 2012-07-17 19:15, Mike Jones wrote:
For clarity of discussion, the definition in question is:
b64token= 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the in
Yes, the decision to remove normative references to HTTPbis was made during the
public OAuth status call on Monday, July 9th, as the call participants wanted
to be able to publish the RFC before HTTPbis is published as an RFC.
The sense on that call was that HTTPbis wouldn't be an RFC until near
On 2012-07-17 19:39, Mike Jones wrote:
Yes, the decision to remove normative references to HTTPbis was made during the
public OAuth status call on Monday, July 9th, as the call participants wanted
to be able to publish the RFC before HTTPbis is published as an RFC.
Well, it would have been ni
The change and the reason for it were called out to the working group in
http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html.
What additional text would you propose that the RFC editor add to explain the
deviance from RFC 2617?
Thanks,
On 17/07/2012 18:15, Mike Jones wrote:
For clarity of discussion, the definition in question is:
b64token= 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the in
You should actually probably make that name change request to the HTTPbis
working group. I suspect that if they decide to change the name, that we could
direct the RFC editor to make the same name change as HTTPbis does.
-- Mike
-Original Message-
From:
On 2012-07-17 19:54, Mike Jones wrote:
The change and the reason for it were called out to the working group in
http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html.
Indeed, as fait accompli. There were four days between the telco and the
publication of the new draft for actually
On 2012-07-17 20:01, Mike Jones wrote:
You should actually probably make that name change request to the HTTPbis
working group. I suspect that if they decide to change the name, that we could
direct the RFC editor to make the same name change as HTTPbis does.
...
HTTPbis describes the produc
On 2012-07-17 20:03, Julian Reschke wrote:
On 2012-07-17 19:54, Mike Jones wrote:
The change and the reason for it were called out to the working group
in http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html.
Indeed, as fait accompli. There were four days between the telco and the
Thanks for the feedback Michael.
4.1.2 is where the authorization code is first talked about, and it makes sense
to discuss how it is generated and used at that point. I can see how it might
also be useful to put it in 4.1.3. Note that this is this is RECOMMENDED as
opposed to MUST so it does n
Thanks for the implementation feedback Michael.
-- Dick
On Jul 17, 2012, at 3:46 PM, Michael Scalia wrote:
> Thanks for your response, Dick, and for pointing out that this is
> RECOMMENDED. I'll just say one more thing about this. While implementing
> the token endpoint of an authorization s
I think mentioning it when code is first described is sufficient.
The token endpoint is normally part of a Authorization server and must both
produce and consume the code.
I understand the request, but duplicating text for every step in a flow that
parameter is used would cause the spec to be m
>> can you please rename the production to something which is clearly not a
>> base64 string.
> HTTPbis describes the production as:
>
> "The "b64token" syntax allows the 66 unreserved URI characters
> ([RFC3986]), plus a few others, so that it can hold a base64, base64url
> (URL and filename sa
20 matches
Mail list logo
