OAuth 2.0 Dynamic Client Registration Protocol
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, oauth mailing list <email@example.com>, oauth chair <firstname.lastname@example.org> Subject: Protocol Action: 'OAuth 2.0 Dynamic Client Registration Protocol' to Proposed Standard (draft-ietf-oauth-dyn-reg-29.txt) The IESG has approved the following document: - 'OAuth 2.0 Dynamic Client Registration Protocol' (draft-ietf-oauth-dyn-reg-29.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/
Technical Summary This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server and the resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. Working Group Summary The work on this document has gone through many iterations but there is strong agreement behind the document. The document has experienced working group last call twice: the first WGLC was in May 2013, which revealed different deployment preferences by various OAuth participants. Here is the link to the initial working group last call: https://www.ietf.org/mail-archive/web/oauth/current/msg11326.html To resolve those disagreements took some time and a new working group last call was started in April 2014 after the document was re-factored and controversial parts had been moved to another specification. Document Quality Various implementations of the dynamic client registration protocol exist. Examples of implementations can be found in the UMA and in the OpenID Connect context, such as phpOIDC (see https://bitbucket.org/PEOFIAMP/phpoidc) Gluu, and Cloud Identity (as reported at the Kantara Initiative website from an interop event that took place this year): http://kantarainitiative.org/confluence/display/uma/UMA1+Interop+Participants+and+Solutions Personnel Hannes Tschofenig is the document shepherd and the responsible area director is Kathleen Moriarty. IANA Note This draft establishes 2 IANA registries. The registry uses the 5226 'Specification Required' with designated expert review to an existing mailing list (email@example.com).