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

[Aiden Bell <[e-mail]>]

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-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
------------------------------------------------------------------
Never send sensitive or private information via email unless it is
encrypted. http://www.gnupg.org