Keeping the conversation from this morning going… This morning I raised the issue that it is not clear to my as to why a client would need to "manage" its registration (note: I think this analysis applies equally to both the the management draft and the earlier SCIM profile I published). What would drive need for a management API would have to come from some lifecycle event in the client software:
1. A new client registers for the very first time (no pre-existing client_id) 2. A client, having registered before is updated in some way (e.g. has a new software statement) where some of its registration information has changed. How can the client notify the server of the change without loosing current authorizations (to maintain user-experience) 3. A client, wants (e.g. because of administrative re-configuration?) to change its registration information 4. A client needs to "rotate" its client credential (client_secret, nego new key etc) 5. A client wishes to de-register 6. A resource server changes its policies. Eg. requiring the client to get a new credential type 7. Others? e.g. meta data change because of a change in language by the user? My view is that most cases can be handled by what is already in the core dyn reg draft (maybe with some explanation). Even when a client updates frequently (as Justin mentions), it does not seem like they would change their metadata between software updates. The only case I can think of is web clients which may be re-configured. But wouldn't they be handled through OOB administration rather than use dyn reg? Phil @independentid www.independentid.com phil.h...@oracle.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
