On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> 2. Single OAuth2 scheme with sub-schemes > > Define a single authentication scheme for all token types with some > attribute used to detect which scheme is actually being used. > > Benefits: > > - single scheme, reuse of the 1.0 pattern. > > Downsides: > > - requires a new registry for authentication header parameters. How is this different from option 1? Wouldn't that need some registry? > - schemes are not easily reusable outside OAuth. Sure. But I really don't see this group trying to create generic authentication schemes. > - existing frameworks usually switch on scheme name, not on sub scheme, > which will cause difficulty in some deployments. I can see this as a potential problem. But considering that there wasn't much objection to use "OAuth" as a scheme name before (total overlap with OAuth 1, and the suggested solution was to look for the signature parameter) I don't see how this is suddenly an issue. Do we have a concrete problem here or this is just theoretical? > - potential to produce a very complicated scheme once many sub schemes are > added. Why? I would argue that this option actually produces more uniform schemes because it forces all of them to be name/value pairs. Beyond token_type everything is scheme specific. I really don't see what is very complicate here. > - requires its own discovery method for which schemes are supported. Why is this a downside only for this option? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
