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

["Fregly, Andrew" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 19, 2016 at 2:30 PM
To: John Bradley <[e-mail]<mailto:[e-mail]>>
Cc: Andrew Fregly <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth