[OAUTH-WG] New Software Statement and Client Association Drafts

[Phil Hunt <[e-mail]>]

As promised, Tony and I have put together a draft proposal as an alternative to the dynamic registration draft.  The relevant links are:
http://datatracker.ietf.org/doc/draft-hunt-oauth-software-statement/
http://datatracker.ietf.org/doc/draft-hunt-oauth-client-association

The two draft proposal provides equivalent functionality to dyn reg. Instead of a new RESTful/json endpoint, this proposal is an assertion centric proposal that adds the following features:

1. Provides a way to recognize client software and ensure all copies register the same way (e.g. redirect_url may be locked for all copies of a mobile app)
2. Registration can be implemented in a stateless fashion (using signed assertions) if desired
3. The association draft uses the normal OAuth token endpoint to issue tokens (improving extensibility for future token types)
4. Has simpler implementation logic resulting from defining 3 different client types and a simple method for each
5. Statements allow service providers to pre-approve client software and set policy (or conversely set broadly open policy)
6. Management API can be supported as an extension if desired (e.g. a version of draft-richer-oauth-dyn-reg-management)
7. Makes bearer tokens the default client credential to "raise the bar" security wise and enable stateless registration (though, client_secret could still be supported -- we should discuss)

Note: the term "association" is meant to have broader scope than the term "registration". It acknowledges that not all clients may actually "register" prior to accessing services (see next paragraph).

The association draft defines 3 client types, each of which is relatively simple to implement (and one of which is just the current "static" registration practice). The other two are "dynamic" and "transient".  The big difference is that "transient" is intended for implicit flow (javascript) clients and eliminates the need to go through a registration step.  "Dynamic" functions by leveraging the token endpoint to exchange software statement and instance specific parameters for a client credential and client registration information and an optional management API endpoint.

We have also tried to provide equivalent functionality as dyn reg by providing approaches for:
*  An initial registration token 
*  Client credential rotation
*  Should work for UMA and OpenID use cases as well as published software cases

Thanks everyone for your contributions and comments!

Phil

@independentid
www.independentid.com
[e-mail]