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

Reply via email to