To Mike's last question below: I'd like Phil (and others if desired) to
propose a clarified version of the "deployment organization", "software
api publisher", and "client developer" if possible. With some text for
that in hand I can tackle the rest given the feedback below.
-- Justin
On 2/1
A few responses and comments are inline below...
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> Sent: Thursday, February 12, 2015 11:47 AM
> To: Justin Richer
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
>
>
> Phil
>
> @independentid
> www.
The OAuth 2.0 Token Exchange
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange specification is
designed for use cases such as yours. Quoting from the abstract:
This specification defines how to request and obtain Security Tokens
from OAuth Authorization Servers, including enablin
Straight impersonation with no limitations isn't a good solution in the long
run.
On Monday, February 16, 2015 1:13 PM, William Denniss
wrote:
I led a discussion on a related topic at a recent IIW (specifically exploring
the "account sharing" use case), the notes are here:
http://
I don't think there is protocol work required. IMO you can best support this
with limited cookies or tokens that are not otherwise valid and the server then
needs to support with the right behavior. Might be a BCP doc I suppose, but I
don't know if it's worth the effort.
On Monday, Febr
Another question is whether or not you can user rights delegation (ie vanilla
OAuth) or if you really do need impersonation. You may be able to get the
desired results with less complexity that way.
-- Justin
/ Sent from my phone /
Original message
From: Bill Burke
Date:0
Yeah, I know its risky, but that's the requirement. Was just wondering
if there was any protocol work being done around it, so that we could
avoid doing a lot of the legwork to make it safe/effective. Currently
for us, we need to do this between two separate IDPs, which is where the
protocol
