draft-ietf-oauth-v2-22 section 8.4 says: "If a response type contains
one of more space characters". I'm pretty sure that should be "one or
more".
Regards,
Andre DeMarre
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
> While you take the viewpoint that the bearer spec is restricting scope
> values, in fact,
> the spec intentionally allows all characters that can be safely communicated
> in an HTTP
> response header parameter to be used.
But "all characters that can be safely communicated in an HTTP response
On 2011-09-26 22:10, Mike Jones wrote:
Getting rid of the b64token would be an unnecessary breaking change.
...
You're at draft state, right?
If you want to keep b64token *and* be able to use params, then you'll
need an alternate syntax that puts the token into param (which,
arguably, would
Getting rid of the b64token would be an unnecessary breaking change.
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Monday, September 26, 2011 12:27 PM
To: William Mills
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP
On 2011-09-26 21:20, William Mills wrote:
I'm gonna top reply...
>> Is that intended and acceptable?
No, b64token isn’t always there; the syntax specifies that either a
b64token OR one or more auth-params will be present. Yes, that’s intended.
If the token can be transported in auth-params
On 2011-09-26 21:03, Mike Jones wrote:
...
No, b64token isn’t always there; the syntax specifies that either a
b64token OR one or more auth-params will be present. Yes, that’s intended.
OK then; just checking :-)
> ...
This was the working group decision at the interim meeting and is used
in
I'm gonna top reply...
>> Is that intended and acceptable?
>
> No,
b64token isn’t always there; the syntax specifies that either a b64token OR one
or more auth-params will be present. Yes, that’s intended.
If the token can be transported in auth-params then I think you must define how
that
While you take the viewpoint that the bearer spec is restricting scope values,
in fact, the spec intentionally allows all characters that can be safely
communicated in an HTTP response header parameter to be used. About whether
those characters employ an encoding methodology to sometimes repres
Sounds good to me. Are others good with this wording?
-- Mike
-Original Message-
From: barryleiba.mailing.li...@gmail.com
[mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
Sent: Saturday, September 24, 2011 6:33 AM
To: Mike Jones
Cc: oa
Thanks for your note, Julian. Responses follow inline...
-- Mike
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Saturday, September 24, 2011 5:07 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: R
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I'm sure you'll all join me in thanking Blaine for all his
> excellent work in bringing oauth into and getting it (almost)
> through the IETF process.
Thanks Blaine!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using G
11 matches
Mail list logo