Thanks for making this change, Eran. I propose that we use Aiden's text,
because I agree that it removes the ambiguity that he identified.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Aiden
Bell
Sent: Tuesday, July 19, 2011 4:39 AM
To: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New
Authorization Endpoint Response Types
I think the wording is much improved here with regards implied relationships
between composite and non-composite types.
However, given this new found unambiguity, I think the use of the term
"composite response types" is misleading, as what is being described is
just a characteristics of "identifiers containing spaces". This newest 8.3
doesn't state if elements in the collection MUST also be registered.
This leads me to (correctly?) think I can register a list of elements where the
components may or may not be registered themselves.
In this case, we have a registered list of response type identifiers rather
than a list of response types registered.
I would propose the following modification, which puts the policy-ish term of
"compounding"
elements, more in the realm of registration, as the term "compounding" seems to
imply compound semantics, but the
registration part has a mechanism-not-policy approach.
The space character (%x20) is reserved for defining a collection of response
type identifiers.
Each collection of response type identifiers MUST be registered, even if
each of its components
are individually registered. The order of components in a response type
identifier collection
does not matter. The meaning of unregistered collections of response type
identifiers made up of
individually registered values is undefined.
For example, the response type "token code" is left undefined by this
specification.
However, an extension can define and register the "token code" response type
identifier collection
and its composite behavior.
Once registered, the same combination cannot be registered as "code token",
but
both values can be used to make an authorization request, and refer to the
same
response type.
Apologies if this is unsuitable, i'm just looking at it as an implementor and
questioning my own assumptions,
then trying to make the text clearer. The validity of my assumptions isn't
presumed.
Thanks,
Aiden Bell
On 19 July 2011 07:21, Eran Hammer-Lahav
<e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote:
I have tried to accommodate both the use cases and concerns raised. The new
text allows the registration of composite response types in which the order of
the space-delimited values does not matter. However, every combination must be
registered in order to avoid developers guessing what an unregistered
combination might mean.
Feedback requested.
EHL
---
8.4. Defining New Authorization Endpoint Response Types
New response types for use with the authorization endpoint are
defined and registered in the authorization endpoint response type
registry following the procedure in Section 11.3. Response type
names MUST conform to the response-type ABNF.
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
The space character (%x20) is reserved for defining composite response types.
Each composite response types MUST be registered, even if each of its
components
are individually registered. The order of components in a composite response
type
does not matter. The meaning of unregistered composite response types made
up of
individually registered values is undefined.
For example, the response type "token code" is left undefined by this
specification.
However, an extension can define and register the "token code" response type.
Once registered, the same combination cannot be registered as "code token",
but
both values can be used to make an authorization request, and refer to the
same
response type.
Also, change the definition of response_type in section 3.1.1:
response_type
REQUIRED. The value MUST be one of "code" for requesting an
authorization code as described by Section 4.1.1, "token" for
requesting an access token (implicit grant) as described by
Section 4.2.1, or a registered extension value as described by
Section 8.4. A value containing one or more space characters (%x25)
identifies a composite response type in which the order of the
space-delimited sub-values does not matter.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
------------------------------------------------------------------
Never send sensitive or private information via email unless it is encrypted.
http://www.gnupg.org
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
