Here is what I think happened.
In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format
arguments were used to allow clients to authenticate themselves to token
endpoints in two legged OAuth scenarios.
In OAuth 2.0 two legged OAuth as a separate definition was removed and instead
merged into three legged OAuth (something that I think is a feature). But in
making this transition the original wrap_assertion and wrap_assertion_format
arguments got turned into assertion_type and assertion.
But (and this part is tricky so please read carefully) assertion_type and
assertion were part of the grant_type structure which was not used for AuthN
(the way client_id/client_secret are) but rather for AuthZ (like refresh
tokens).
Having assertion/assertion_type was still a very good improvement in the
protocol since we have plenty of real world scenarios where we need to use
assertions for AuthZ but the change left a big hole - how do use an assertion
for AuthN?
That's where the client_assertion/client_assertion_type come in.
So the whole confusion really seems to have come about because OAuth in doing a
good thing (unifying 2 and 3 legged patterns) ended up moving assertions from
AuthN to AuthZ, which was actually a new (and useful) feature but as a
consequence created a hole that didn't exist with WRAP when dealing with AuthN.
So by putting in client_assertion/client_assertion_type and keeping
assertion/assertion_type we get the best of all worlds. We can now use
assertions for both AuthN and AuthZ.
Yaron
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Wednesday, July 07, 2010 2:03 PM
> To: Eran Hammer-Lahav
> Cc: Hannes Tschofenig; OAuth WG
> Subject: Re: [OAUTH-WG] assertion profile changes
>
> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav
> <e...@hueniverse.com> wrote:
> > It is pretty much the same as originally proposed. Any recent changes
> > are an oversight, not any intentional change. Since it was proposed,
> > the only change made (with full consensus) was to allow client
> > authentication as an optional request parameter, as well as allow a
> > refresh token as an optional response parameter.
>
> Can you point me to the e-mail threads that reached consensus on using
> client authentication?
>
> Can you point me to the e-mail threads that reached consensus on returning
> a refresh token?
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
