Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types

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-bounces@ietf.org [mailto:oauth-bounces@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 <eran@hueniverse.com<mailto:eran@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