On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Client assertion credentials: > > The mechanism is under specified, especially in its handling of the > client_id identifier (when used to obtain end-user authorization). > It does not contain any implementation details to accomplish any level of > interoperability or functionality.
Google has plans to use client assertions as well. We have two use cases, one indeed would require an additional extension to specify details about the content and format of the assertion. But the other would work with what currently exists in v11. In both cases the client cannot send the secret as authentication (either for technical or security reasons) and instead it sends an assertion. In the fist case the client is self issuing an assertion, and in this case we need more details. In the second case the client gets an assertion from a local IdP. In this case the local IdP and the remote OAuth 2 Authorization Server do need to agree on keys and formats, but the client does not need to understand any of that. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
