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

Get OpenID Connect id_token by the authentication request with prompt=none
and verifying the sub to be the same with what you expected seem to suffice
your needs. Am I missing something?
On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew <afregly@verisign.com> wrote:

> Thanks for your response John. I also got a good response from Brian
> Campbell and appreciate that. I will respond separately to Brian’s response
> as I think it would keep things clearer to do that.
>
> The problem we have for using OpenID Connect is that it combines the role
> of Authentication Service with the role of Authorization Service. Perhaps
> the following description of what we want to do will clarify why this won’t
> work for us:
>
> The basic problem statement is that we need to have a client application
> authorized by a Service Provider based on proof that a user is currently a
> member of some organization. This assumes the organization has previously
> established some level of authorized access with the Service Provider.
>
> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose SomeOrg
> Inc. is doing research that requires it to gather data over the Internet
> from a number of data providers. The data providers require authentication
> and proof of organizational membership in order to authorize various levels
> of access to their data. The data providers do not consider having an
> account with them or a Public Identity Provider to be suitable for proving
> that I am still a member of SomeOrg at time of authentication. They would
> have no way of knowing whether or not my relationship with SomeOrg still
> exists at that time. The data providers would therefore like the Client
> software to authenticate me against SomeOrgs Identity Provider. This would
> be good proof that I am still a member of SomeOrg at the time I
> authenticate. This authentication would enable the data providers
> Authorization Server to grant me access appropriate to a member of
> SomeOrg.  Note that as a prerequisite to all of this, SomeOrg will have
> used an out-of-band process to set up a trust relationship for SomeOrg's
> Identity Provider with the data provider’s Authorization Service, and will
> have negotiated authorization claims to be granted to SomeOrgs members.
>
> What I am having difficulty with is in knitting together an approach based
> on the he OpenID Connect specifications, SAML specifications, and OAuth
> RFCs and drafts in a way that supports the above use case end-to-end. The
> OAuth RFCs and drafts almost get me there. What seems to be missing is a
> way of telling an Identity Provider the URL for the Authorization Service
> (the required Audience claim in an authentication assertion as defined in
> RFCs 7251, 7252 and 7253), and then a requirement that the Identity
> Providers put the supplied Audience Identifier into Authentication Tokens.
> Perhaps a little further back-and-forth with Brian will resolve this.
>
> I can go into deeper detail if needed. If this is off-topic for the OAuth
> working group, let me know.
>
> Thanks,
> Andrew Fregly
> Verisign Inc.
>
>
> From: John Bradley <ve7jtb@ve7jtb.com>
> Date: Tuesday, April 19, 2016 at 2:06 PM
> To: Andrew Fregly <afregly@verisign.com>
> Cc: "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
>
> 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
>