Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

[Lukas Rosenstock <[e-mail]>]

+1

While it's good to have one document, it's better to have two good documents
instead of one that we're unhappy with.

There'll be "Implementer's Guides" and "Tutorials" later who will do the job
of explaining how to make sense of the two (which of course doesn't mean I'm
advocating specifications which are hard to understand without other
material).

2010/9/28 Eran Hammer-Lahav <[e-mail]>

> 1. Add a parameter to the token response to include an extensible token
> scheme.
>
>
>
> The default (if omitted) will be whatever the bearer token scheme is
> called. This will allow the authorization server to return any token type it
> deems appropriate, and for other specifications to define additional
> parameters such as token_secret. Others can extend the token request
> endpoint by allow the client to request a specific token scheme.
>
>
>
> 2. Break the core specification into multiple parts.
>
>
>
> Go back to the original working group consensus to break the document into
> two parts: getting a token and using a token. Getting a token will include
> everything from core expect for section 5. Section 5 will become a new
> specification which will describe how to use a bearer token (replacing the
> generic ‘OAuth’ scheme with something more descriptive like).
>
>
>
> 3. Introduce two signature proposals in one or more documents, for the JSON
> token and 1.0a-like method.
>
>
>
> One, both, or none can become working group item.
>