Lahav
> Cc: oauth@ietf.org
> Subject: RE: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13
>
> Actually, despite having submitted this comment, I'm having second
> thoughts about it as well based upon some possible use cases I'm aware of.
> If, for instance, a scope element contai
Authentication scheme names in HTTP are case insensitive.
From: "Zeltsan, Zachary (Zachary)"
To: 'Eran Hammer-Lahav'
Cc: OAuth WG
Sent: Friday, March 25, 2011 11:33 AM
Subject: Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13
The
The spelling of the name "Bearer" authentication scheme in the draft is
inconsistent with the spelling in
draft-ietf-oauth-v2-bearer-03.
In draft-ietf-oauth-v2-13, section 7.1:
"For example, the "bearer" token type defined...",
and
"Authorization: BEARER h480djs93hd8"
In draft-ietf-oauth-v2-bea
g] On Behalf Of Brian
Campbell
Sent: Friday, March 25, 2011 9:17 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13
It didn't align with the my assumption when I was implementing, which is why I
asked:)
With respect to URIs, I believe that
ions. Also, in the case
> of URI values, they are usually case insensitive.
>
> EHL
>
>> -Original Message-
>> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
>> Sent: Friday, March 25, 2011 8:00 AM
>> To: Eran Hammer-Lahav
>> Cc: Mike Jones;
-Lahav
> Cc: Mike Jones; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13
>
> >> 4.1.1: Scope string matching rules are ambiguous
> >>
> >> In the "scope" definition, add "The space-delimited strings are case
> >
>> 4.1.1: Scope string matching rules are ambiguous
>>
>> In the "scope" definition, add "The space-delimited strings are case
>> insensitive."
>
> Good call.
I'd like to better understand why? Other than a means to delimit and
allow for multiple values, the spec is otherwise leaving the
interpr
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mike Jones
> Sent: Tuesday, March 15, 2011 7:52 AM
> 2.1.1: "If no valid redirection URI is available, the authorization server
> SHOULD" - I don't understand why this is a SHOULD and not
My last call feedback on draft 13 follows.
NORMATIVE FEEDBACK
2.1.1: "If no valid redirection URI is available, the authorization server
SHOULD" - I don't understand why this is a SHOULD and not a MUST
3: Restore Client Assertion Credentials
Restore the Client Assertion Credentials feature t
