Hi. Le mercredi 25 novembre 2009 à 08:58 -0500, Steve K Speicher a écrit :
> Since the terms "authorization" and "authentication" are overloaded, I > think it would be best instead of me trying to describe OAuth here > that I defer to the http://oauth.netsite for resources that describe > it. > > I did not intend to state a subset of OAuth or misrepresent it by > saying "cross-system authentication" as it is not a single-sign on > solution. It provides a way to authenticate users, then leverage that > to authorize cross-server access. You're right... reading back your initial message, the term authentication had triggered some doubts, but I hadn't really noticed the "cross-system auth". OAuth is really about tokens granted by apps to other apps after approval by users, and not a *users* auth mechanism nor a SSO indeed. Thanks for the clarification. I think we share the same vision of OAuth's role in the protocol. What's left to define (maybe ?) is the semantics of such privileges/permissions that the servers would support with OAuth maybe ? Would it be part of the OSLC-CM standard to explicitely state which permissions may be granted to clients through OAuth ? For instance I can imagine a use case for a system where a user could be prompted to allow delegation of the right to create bugs in a bugtracker to a continuous integration tool for a specific "project" or "category" only, but not to mark bugs as resolved. The "right to create a bug in a particular project" or "right to mark a bug as resolved" would then be the kind of permissions granted to client tools through OAuth ? That's a bit different than being allowed to access a particular URL through POST (as may be easily done with a .htaccess for instance). How "far" should OSLC-CM go in this respect in terms of standardization ? Best regards, -- Olivier BERGER <[email protected]> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
