Okay, sorry, I see the distinction you were making. The client could potentially be told the client_assertion_type and given the assertion (assuming it's properly encoded for all the hops) by some IdP/STS and make use of the use of the spec, as it is written in -11. Maybe then some clients could support stronger forms of authentication for OAuth without knowing about or being coded for an extension. Maybe. But they still would need to know how to get the assertion and URI which is another animal all together.
On Thu, Jan 20, 2011 at 2:38 PM, Marius Scurtescu <mscurte...@google.com>wrote: > On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell > <bcampb...@pingidentity.com> wrote: > > 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. > > I do agree that an extension would be useful for the second case, but > I don't think the client needs to know about it. I think it is > somewhat similar with the situation of the scope parameter. > > Marius >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
