Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

And that Identity Provider organization could also have it's own
authorization server that could act as an STS. That's all I was trying to
say. I'm not sure if that would help your case.

On Tue, Apr 19, 2016 at 2:19 PM, Fregly, Andrew <afregly@verisign.com>
wrote:

> Brian,
>
> Once again, thank you for your input. Per my prior response to John
> Bradley, our use case has the Identity Provider being provided by a
> different organization than the organization providing the Authorization
> Service.
>
> Thanks,
>      Andy
>
> From: Brian Campbell <bcampbell@pingidentity.com>
> Date: Tuesday, April 19, 2016 at 2:30 PM
> To: John Bradley <ve7jtb@ve7jtb.com>
> Cc: Andrew Fregly <afregly@verisign.com>, "oauth@ietf.org" <oauth@ietf.org
> >
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0
> Token Exchange: An STS for the REST of Us” to include Authentication Tokens
>
> The Token Exchange draft does put the Authorization Server (AS) in the
> role of STS because it's an extension of OAuth. But that shouldn't be
> viewed as limiting. An AS is often deployed as one part of an Identity
> Provider. OpenID Connect, as John mentioned, is one standard that combines
> the roles. And many products/services/deployments have an AS as part of
> their overall Identity Provider offering, which might also have OpenID
> Connect, SAML, etc.
>
> On Tue, Apr 19, 2016 at 12:06 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>> Looking at OpenID Connect and it’s trust model for producing id_tokens
>> that assert identity may help you.
>> http://openid.net/wg/connect/
>>
>> Unfortunately I can’t quite make out what you are trying to do.
>>
>> It sort of sounds like you want an id_token from a idP and then have the
>> client exchange that assertion for another token?
>>
>> John B.
>>
>> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <afregly@verisign.com> wrote:
>>
>> I have a use case where a client application needs to authenticate with a
>> dynamically determined Identity Provider that is separate from the
>> Authorization Service that will be used issue an access token to the
>> client. The use case also requires that as part of authorization, the
>> client provides to the Authorization Service an authentication token signed
>> by an Identity Provider that the Authorization Service has a trust
>> relationship with. The trust relationship is verifiable based on the
>> Authorization Service having recorded the public keys or certificates of
>> trusted Identity Providers in a trust store, this allowing the
>> Authorization Service to verify an Identity Provider’s signature on an
>> authentication token.
>>
>> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and
>> 7523, I see that they get me close in terms of supporting the use case.
>> What is missing is a means for solving the following problem. These RFCs
>> require that the Identity Provider put an Audience claim in the
>> authentication token. The problem with this is that I do not see in the
>> RFCs how the Identity Provider can be told who the Audience is to put into
>> the authentication token. This leads me to the title of this message. The
>> draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” defines a
>> mechanism for identifying the Audience for an STS to put into a token it
>> generates. That would solve my problem except that the draft limits the
>> type of STS to being Authorization Servers. What is needed is this same
>> capability for interacting with an Identity Provider. This would enable
>> RFCs 7521, 7522 and 7523 to be useful in situation where the Identity
>> Provider needs to be told the identity of the Authorization Service.
>>
>> I am new to interacting with the IETF. I also am not an expert on the
>> RFCs or prior history of the OAuth group relative to this topic, so please
>> point me to any existing solution if this is a solved problem. Otherwise, I
>> would like to get feedback on my suggestion.
>>
>> Thanks You,
>>
>> Andrew Fregly
>> Verisign Inc.
>> _______________________________________________
>> 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
>>
>>
>