If you have a confidential client using a traditional symmetric secret, from the client's perspective you wouldn't pack the secret into the client_id with this method any more than you would pack it into the client_id using a normal method -- at least as far as the client is concerned, they're two separate and unrelated values, generally treated as opaque. Ideally with a stateless client you'd be using some kind of asymmetric key with the assertion profile or something like that for client auth, and I think that's going to be the most common case for people who are doing a truly stateless server environment, but there are a few other ways you could handle it.
As John points out in another thread, you could encrypt the claims set to the AS's key. This would let you put the secret itself directly inside the client_id without the client being able to muck about with it, and without exposing it to the browser or other agents that get the client_id (which, you must remember, is essentially public information). Alternatively, you could tie the client ID to the secret by issuing a signed JWT as the client_secret as well, with the client_secret's JWT containing the same subject as the client_id's JWT. There are probably some other tricks you could do, but these are the cleanest two that come to mind for me. Maybe others can fill in on what those might be. -- Justin On Oct 15, 2013, at 5:06 AM, Pedro Felix <pmhsfe...@gmail.com<mailto:pmhsfe...@gmail.com>> wrote: Hi, Is this applicable to public (non-confidential) clients only? For confidential clients, the verification of the client_secret doesn't seem to be addressed by this proposal (token endpoint interactions). We could however extend it to address this scenario, namely by using encrypted JWTs with client_secret verification information. Thanks Pedro On Tue, Oct 15, 2013 at 1:01 AM, John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote: A new version of I-D, draft-bradley-stateless-oauth-client-00.txt has been successfully submitted by John Bradley and posted to the IETF repository. Filename: draft-bradley-stateless-oauth-client Revision: 00 Title: Stateless Client Identifier for OAuth 2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt Status: http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client Htmlized: http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00 Abstract: This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
