get the semantics of (2)
>> without (1). Now the semantics of combing (1) and (2) seem to be not
>> understood and wanting to be removed.
>>
>>
>>
>>
>>
>> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Justin
>> Richer
>> *Sent
t; *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Justin Richer
> *Sent:* Saturday, August 27, 2016 3:26 PM
> *To:* Brian Campbell
> *Cc:*
> *Subject:* Re: [OAUTH-WG] Following up on token exchange use case
>
>
>
> No objections. Simplification is better, and th
to be removed.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Saturday, August 27, 2016 3:26 PM
To: Brian Campbell
Cc:
Subject: Re: [OAUTH-WG] Following up on token exchange use case
No objections. Simplification is better, and this spec is already fairly
No objections. Simplification is better, and this spec is already fairly
convoluted with all the options turned on.
— Justin
> On Aug 26, 2016, at 1:30 PM, Brian Campbell
> wrote:
>
> Looking for two things here:
>
> 1) Any objections to removing the want_composite request parameter? Please
Looking for two things here:
1) Any objections to removing the want_composite request parameter? Please
explain, if so. I plan to remove it in the next draft barring an outpouring
of support to keep it.
2) Tony to explain his use case and describe what changes would be needed
to accommodate it.
During the meeting in Berlin Tony voiced concern about a use case he had
for token exchange. Honestly, it's still not entirely clear to me what that
use case is or what would need to change in support of it. I'd like to
better understand the use case and see if it's something that can
reasonably be
