OAuth Extensions

Convener

John Panzer

Attendees

• Kevin Turner - Janrain Inc.
• Josh Hoyt - j3h.us -
• Jason Amster - BeenVerified
• Richard M. Conlan - Google
• Jim Pravetz - Adobe
• George Fletcher - AOL
• Pat Patterson - Sun Microsystems
• Allen Tom - Yahoo
• Markus Sabodello - Parity
• John Panzer - Google
• Praveen Alavilli - AOL
• Wei Tu - Google
• Devlin Daley - BYU
• Bryant Cutler - BYU
• Shreyas Doshi - Yahoo
• Breno DeMedeiros - Google
• Eran Hammer-Lahav - Hueniverse
• Terrell Russell - claimID.com
• Joseph Smarr - Plaxo
• Lena Kannappan - FuGen Solutions
• Sam Alexander - Vidoop LLC
• Travis Phipps - Vidoop
• Jeff Shan - eTrade
• Casper Biering - Netamia

Notes

Summary: OAuth extensions are the path for incrementally adding to the spec. Now that the core is stable the intent is to start immediately on the necessary extensions and see which ones gain traction; those with wide adoption would be part of the de facto standard.

Governance? 2 ideas: A body which approves extensions which have "oauth" name on them. Other idea: Like HTTP, X-. Middle ground: Wiki to formulate ideas, once have something more concrete then post on Wiki as full blown spec or new field with semantics. Enough people have write access so that it's community oriented still; like Apache contributor model. Seemed to be general agreement that a committee is too much work.

Two kinds of extensions: Add parameters, no more parameters can be added to core 1.0 oauth_ namespace. Language extension will need to add a parameter. Signature methods don't necessarily need to add parameters, just a new value. Or canonical URLs or discovery methods.

Would have a good idea to have another namespace for oauth extensions (x_oauth)?

Two google groups: oauth, and oauth-extensions.

Need a way to auto discover extensions; libraries can adjust to be able to use parameters as needed so would isolate apps from most of the detail work.

List of discussed extensions thus far:

• Discovery of things like endpoints, methods, signatures, and extensions supported in a machine readable way. Want to support a way for the WWW-Authenticate header to point at metadata that allows automatic discovery. • Permissions: Document constraints on tokens and have language for requesting permissions. • Error handling. • Language setting. • Preapproved transactions use case. • Signature method extensions. • Hints for UI -- small UI, small tokens. • Document constraints on tokens. • Terms-of-service agreements for consumers & SPs. • Managing consumer keys centrally for multiple services.

Best practices section on Wiki? (Existing BPs turned into Appendix B.) When trying to merge or marry different protocols.

IPR question: Some organizations have IPR policies that may block participation, can/should we adopt the OpenID IPR process? (Allen Tom) (Chris M. following.)

DISCOVERY EXTENSION:

Want to be able to point at a single discovery URL that is machine readable, lets you declare and discover extensions. Can find URL to XRDS file from WWW-Authenticate challenge (new param), or from docs (just configure your client), or potentially from HTML META tags (there's a standard for this).

Example (worked up) of XRDS file:

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:oauth="http://oauth.net/core/1.0" xmlns="xri://$xrd*($v*2.0)">
	<XRD>
		<Service>
			<Type>http://oauth.net/core/1.0/endpoint/request</Type>
			<oauth:SignatureMethods>PLAINTEXT,HMAC-SHA1</oauth:SignatureMethods>
			<oauth:HttpMethod>POST</oauth:HttpMethod>
			<URI>https://api.nouncer.com/session/request</URI>
		</Service>
		<Service>
			<Type>http://oauth.net/core/1.0/endpoint/authorize</Type>
			<URI>https://api.nouncer.com/session/login</URI>
		</Service>
		<Service>
			<Type>http://oauth.net/core/1.0/endpoint/access</Type>
			<Type>http://oauth.net/experimental/foo/1.0/</Type>
			<oauth:SignatureMethods>PLAINTEXT,HMAC-SHA1</oauth:SignatureMethods>
			<oauth:HttpMethod>POST</oauth:HttpMethod>
			<URI>https://api.nouncer.com/session/activate</URI>
		</Service>
		<Service>
			<Type>http://oauth.net/core/1.0/endpoint/resource</Type>
			<oauth:SignatureMethods>HMAC-SHA1</oauth:SignatureMethods>
		</Service>
	</XRD>
</xrds:XRDS>

General agreement in the room that this seems reasonable, and is extensible, and a separate document is necessary.

Last point from Praveen A.: There's no good story for returning errors back to the user esp. in the case of desktop clients.