I'd argue that, for reliable interoperability, both of those cases would require an extension or at least some level of agreement about the format and validation rules of the assertion.
On Thu, Jan 20, 2011 at 2:08 PM, Marius Scurtescu <[email protected]>wrote: > On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
