+1 for Jame's feedback here. We need to solve this.
________________________________
From: "Manger, James H" <james.h.man...@team.telstra.com>
To: Barry Leiba <barryle...@computer.org>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, August 18, 2011 4:15 AM
Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
>> * For bearer tokens: clarification whether the non-support of percent
encoding for scope-v element of WWW-Authenticate Response Header Field
grammar is intentional.
> Answer:
> In the bearer token document (Section 2.4 of
> draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header
> Field"), the "scope-v" element is unambiguously defined to allow a
> specific set of characters. That set of characters does permit, but
> does not mandate, support for percent-encoding of characters.
This is a poor answer.
A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..."
response will either compare it with strings from a OAuth2 JSON-encoded token
response, or copy it into a request to an authorization server. It needs to
know if it needs to %-decode the value or not before doing these things.
Clients cannot be expected to behave differently for different servers in this
respect.
OAuth2 core (implicitly) allows a scope to use any Unicode char except space
(as space is used as a delimiter).
Bearer restricts scopes to 93 ASCII chars.
OMA are asking if this is intentional.
If we really want to restrict scope values it would be better done in OAuth2
core.
If we don't want to restrict values then the bearer spec needs to be able to
handle any possible scope value by defining an escaping mechanism for scope-v
(or by not having a scope parameter).
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
