From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>,
 OAuth WG <oauth@ietf.org>
Date: Fri, 25 Jun 2010 10:59:50 -0700
Thread-Topic: Extensibility for OAuth?
Thread-Index: AcsSmmOz8+Jt3DWXRJyOV1i4UkJelAB9HoEA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Extensibility for OAuth?
Precedence: list

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Tuesday, June 22, 2010 11:08 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Extensibility for OAuth?
>=20
> Hi Eran,
> Hi all,
>=20
> I briefly browsed through the -08 version of the draft to figure out what
> could be written about extensibility. Here are a few thoughts:
>=20
> - Client Profiles
>=20
> This is probably the most important item were people will want to write
> extensions for. Currently, we have the following onces in the document:
>   1) Web Server
>   2) User Agent
>   3) Native Application
>   4) Autonomous
>   Note that the actual profile identifiers aren't clearly listed in the d=
ocument
> at the moment (or are inconsistent, such as "user_agent" and "user-agent"
> for the user agent profile).

Profiles are not normative language, they are just examples of the authoriz=
ation and token endpoints can be used (profiled) for particular use cases (=
the most common ones). This is why this has been moved to the introduction.=
 Instead, the spec now talks about grant types, providing three primary typ=
es (user basic credentials, authorization code obtained from the authorizat=
ion endpoint, and assertion). The assertion type is the generic extension p=
oint using a URI-formatted assertion type (which does not require a registr=
y).

I would rather limit the ability to extend the two endpoints beyond their c=
urrent architecture, and instead, allow others to specify new endpoints (e.=
g. a device endpoint for getting an authorization code without using browse=
r redirection) that work in addition to the token endpoint (using an existi=
ng grant type or assertion).

> We would want IANA to register them and then we need to list under what
> conditions new profiles can be added, or existing onces updated/deleted.
> RFC 5226 defines some typical policies, see
> http://tools.ietf.org/html/rfc5226.
> We probably want the policy "RFC Required". When people write new
> profiles we want them to provide a description about the use case, maybe =
an
> example, we want them to discuss security, and  we definitely want to
> ensure that the overall write is consistent with the base specification (=
such as
> with the registry parameters it defines). The reviews would ensure that
> existing profile do not in fact already provide the functionality of the =
newly
> defined profile. Note that "RFC Required"
> does not require a Standards Track RFC; an Informational or an Experiment=
al
> RFC is already sufficient. Those are less difficult to get published but =
they still
> provide a stable reference.

I think Specification Required is better for most registries.

> - Error Codes
>=20
> The document lists error codes in Section 3.1 and Section 4.3. I suspect =
that
> they are not from the same pool of error codes.
>=20
> My question is whether some of the error codes are very specific to the
> profiles themselves or rather generic in nature.

I'm working to clean up errors in -09.

> - Grant Type
>=20
> The Grant Type (grant_type) is described in Section 4. Currently, there a=
re 5
> values defines ("authorization_code", "user_basic_credentials", "assertio=
n",
> "refresh_token", "none") and I assume that the list should be extensible
> (even though the text currently says something else at the moment).
>=20
> Are there specific requirements that must be met in order to register new
> grant types?

I would rather not allow for new grant types. I think the assertion type of=
fers as much extensibility as needed. However, I am going to propose we all=
ow extension parameters to both endpoints.

> - Assertion Type
>=20
> Section 4.1.3 defines the assertion type ("assertion_type"). The text
> indicates that the content is an absolute URI and as such it is a bit dif=
ferent to
> the other value encodings we have seen previously.
> Nevertheless, the question is whether some folks want to write
> standardized templates for assertions, such as a specific form of SAML
> assertion. This could help interoperability a lot, I believe. The solutio=
n is still
> to have a URI but to define an IANA managed space for IETF standardized
> assertion types. Such a style is btw common.

I am not sure this is needed. URIs provide name collision protection. Beyon=
d that, people should write specs as needed.

EHL