We can setup a wiki page as a starting point while people wait for the IANA
registry.
EHL
On 4/15/10 11:48 AM, "record...@gmail.com" <record...@gmail.com> wrote:
I think there will be a warming up period though as vendors prototype
with parameters before any sort of registry is setup. This should be
manageable given that we have a fairly small community right now
working on the spec.
On Thu, Apr 15, 2010 at 11:46 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> Me too. I think a vendor-name prefix will work just fine. By definition
> anything with a prefix-period will be defined as vendor-specific and not for
> interop. As long as we keep the registration lightweight people should
> register new parameters and increase interop.
>
> EHL
>
>
> On 4/15/10 11:37 AM, "record...@gmail.com" <record...@gmail.com> wrote:
>
> I prefer no extension URIs since they make requests longer and really
> have never taken off in OpenID.
>
>
> On Thu, Apr 15, 2010 at 11:27 AM, Eran Hammer-Lahav <e...@hueniverse.com>
> wrote:
>> OAuth 2.0 flows use a single authorization endpoint (with 'type'
>> parameter).
>> This endpoint is OAuth-specific but must allow for extension parameters
>> (standard or vendor-specific).
>>
>> The issue is how to best allow for extensions defining new parameters. The
>> danger is common parameter names ('scope', 'language', 'permission') being
>> used differently by different vendors, creating interop issues with
>> libraries.
>>
>> Prefix alone (for the core or extensions) does not solve the problem since
>> extensions still suffer from potential namespace collision. 'oauth_'
>> prefix
>> makes all the parameter names longer, but doesn't add real value -
>> defining
>> new parameters, with or without the 'oauth_' prefix is still the same
>> problem.
>>
>> The typical solution is to define an extension policy, using a registry or
>> domain-namespace for new names.
>>
>> Proposal:
>>
>> Plain parameter names (names without '.' character) require registration
>> (IANA registry with a published specification). This will encourage people
>> to share their parameters and improve interop beyond the core protocol
>> parameters.
>>
>> Vendor specific names will require a prefix using either registered vendor
>> names (e.g. 'google', 'fb', 'yahoo'). Alternatively, use the same
>> extension
>> policy as OpenID where extensions use any prefix and include a prefix URI
>> identifier (e.g.
>> http://example.com?etx.language=en&ns:ext=http://example.com/spec1).
>>
>> EHL
>>
>> _______________________________________________
>> 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
