I'd say it should be a MUST so that implementations are consistent about it.
On Fri, May 16, 2014 at 3:27 PM, Bill Mills wmills_92...@yahoo.com wrote:
The HTTP specs don't limit these things, but implementations do, and the
problems when you run into them are a rea pain.
DO we want to make
Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security token
service (STS) where they can obtain assertion grants and the AS trusts the
STS to issue such assertions. In that kind of scenario, the identity of the
Hi,
Thanks for the clarification,
On 20/05/14 14:03, Brian Campbell wrote:
Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security
token service (STS) where they can obtain assertion grants and the AS
trusts
On 5/20/2014 10:04 AM, Sergey Beryozkin wrote:
Hi,
Thanks for the clarification,
On 20/05/14 14:03, Brian Campbell wrote:
Yes Sergey, it's to allow for support of unregistered clients. Typically
such clients will have some relationship established with a security
token service (STS) where
Sergey - you haven't missed anything. The client remains unregistered
throughout the exchange.
There is no relationship between the assertion grant (or access token)
and the client either.
You are pointing out that an AS endpoint supporting unregistered clients
(public in OAuth terminology)
Hi Prateek
On 20/05/14 16:00, Prateek Mishra wrote:
Sergey - you haven't missed anything. The client remains unregistered
throughout the exchange.
There is no relationship between the assertion grant (or access token)
and the client either.
You are pointing out that an AS endpoint supporting
The difference between the two scenarios is that the authorization code
has a one-use property and also requires the user to be present.
These conditions are not available in the (assertion grant -- access
token) with a public client. So there are some fundamental differences
in security
