[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]

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.

[John Bradley]

Looking at OpenID Connect and it’s trust model for producing id_tokens that assert identity may help you.
http://openid.net/wg/connect/ <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.

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
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[Brian Campbell]

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.

Post by John Bradley
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.
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Fregly, Andrew]

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 <***@pingidentity.com<mailto:***@pingidentity.com>>
Date: Tuesday, April 19, 2016 at 2:30 PM
To: John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>
Cc: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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.com<mailto:***@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 <***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

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.

Post by Fregly, Andrew
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
Date: Tuesday, April 19, 2016 at 2:30 PM
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.

Post by John Bradley
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.
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Fregly, Andrew]

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.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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 <***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

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?

Post by Fregly, Andrew
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
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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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.
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Fregly, Andrew]

Thanks for your reply Nat.

Does your approach match with an IETF OAuth RFC or Draft describing how an Authorization Service can accept and verify an authentication token provided by a client during the authorization process? If so, please point me to that. The only RFCs I have seen that address this are RFCs 7251, 7252 and 7253, and they all have a requirement that an “audience” claim corresponding to the Authorization Service is in the authentication token. Getting that claim into an authentication token provided by an Organization’s Identity provider seems to be my fundamental problem.

Thanks,
Andy

From: Nat Sakimura <***@gmail.com<mailto:***@gmail.com>>
Date: Tuesday, April 19, 2016 at 4:13 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

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 <***@verisign.com<mailto:***@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.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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 <***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

Hi Andrew,

In OAuth 2.0, the resource owner authentication /end user authentication is
out of scope. What it deals with is "client authentication". They should
not be mixed up. There is no end user identity nor authentication token in
the OAuth. You cannot do end user authentication with pure OAuth. For that,
you have to rely on something like OpenID Connect.

As John noted, it is perfectly fine to chain the external authentication
and the internal authorization. It is often done. It is just that the
RFC6749 Authz server is an RP of OpenID Connect or SP of SAML. Nothing
precludes it.

If you really want to avoid the front channel re-auth with prompt=none,
which is more secure and proper ways to do, but just to make sure that the
user still exists in the authentication service, you can infer it by making
a userinfo request to the userinfo endpoint of OpenID Connect. It would
fail in various reasons, but would certainly fail if the user does not
exist anymore. Other error conditions like the user revoked the
access/refresh token etc. would cause the same invalid_token error though.

Best,

Nat

P.S. I do not see why the RFCs you sited are relevant here. I guess you are
talking about RFC7521-7523 ;-)

RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC7252 The Constrained Application Protocol (CoAP)
RFC7253 The OCB Authenticated-Encryption Algorithm

Post by Fregly, Andrew
Thanks for your reply Nat.
Does your approach match with an IETF OAuth RFC or Draft describing how an
Authorization Service can accept and verify an authentication token
provided by a client during the authorization process? If so, please point
me to that. The only RFCs I have seen that address this are RFCs 7251, 7252
and 7253, and they all have a requirement that an “audience” claim
corresponding to the Authorization Service is in the authentication token.
Getting that claim into an authentication token provided by an
Organization’s Identity provider seems to be my fundamental problem.
Thanks,
Andy
Date: Tuesday, April 19, 2016 at 4:13 PM
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
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?

Post by Fregly, Andrew
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
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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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.
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Fregly, Andrew]

Thank you again of your input Nat.

First of all, I apologize for confusing the situation by referencing the wrong RFCs in a prior email. I transposed two digits. The RFCs I meant to reference where 7521-7523 (see below).

I get that the original RFC for OAuth has the mechanism for client authentication being out of scope. What is muddying the water for me is that RFCs 7521, 7522, and 7523 seem to specify the means by which a client can provide an authentication token to an Authorization Service. This purpose is stated at the top of the abstract for RFC 7521:

"The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.”

In our use case, we need to have users authenticated against identity providers that organizations use internally as the means for authenticating clients accessing our service. We need this because we believe this is the best means for proving a user is still a member of an organization at the time they authenticate. Most, perhaps all of these organizations, will internally use an Identity Provider that provides SAML authentication assertions. This led me to looking for a way to use authentication tokens produced by internal Identity Providers as a means for proving a client had been authenticated by the organization. A bit of investigation in how this might be done led me to OAuth RFCs 7521, 7522 and 7523. They almost get me there. They specify what needs to be in an Authentication token that is given by a client to an Authorization Service. The gotcha was that these RFCs require an audience claim in the authentication token. This audience claim is used to identify the specific Authorization Service the token is meant for. For this audience claim to get filled in by some arbitrary organization’s Identity Provider, it seems the Identity Provider will need to be told who the Authorization Service is by the client initiating the authentication. I have therefore been looking for a standard that specifies how a client can tell the Identity Provider the identity of the Authorization Service. I was stuck for a bit on how the IETF OAuth working group could address this issue since authentication seemed to be out of scope for the group. Then I found the IETF draft "OAuth 2.0 Token Exchange: An STS for the REST of Us”. It defines a mechanism for telling a Security Token Service the audience for the token it is being asked to issue. I thought that would solve my problem since an intent of the draft seemed to be on generalizing the described approach to any type of Security Token Service. There was one gotcha in the draft though. It limited the type of STS to which the protocol applied to be just Authorization Services. For my use case, I needed the capability described in the draft, but applicable to Identity Providers too. If it were applicable to Identity Providers, there would then be a full set of existing RFCs and drafts that covered the functionality needed for our use case.

There are a couple of possible actions that I have been contemplating relative to OAuth:

1. Write extensions to RFCs 7521, 7522 and 7523 that eliminate the need for an audience claim in the authentication token if the Authorization Service has a trust relationship with the Identity Provider that issued the authentication token.
2. Ask the authors of the “OAuth 2.0 Token Exchange: An STS for the REST of Us” to explicitly state that the the approach described there-in is applicable to both Identity Providers and Authorization services.

Before doing either of these steps, I want to make sure that I am not missing something in existing RFCs and drafts that would address our use case. I have only been looking at this issue for a few weeks, so I thought it would be best to go to the experts to get advice. This led to this email chain.

Thanks to all following this chain for your time and consideration on this!

Andy

From: Nat Sakimura <***@gmail.com<mailto:***@gmail.com>>
Date: Tuesday, April 19, 2016 at 5:35 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

Hi Andrew,

In OAuth 2.0, the resource owner authentication /end user authentication is out of scope. What it deals with is "client authentication". They should not be mixed up. There is no end user identity nor authentication token in the OAuth. You cannot do end user authentication with pure OAuth. For that, you have to rely on something like OpenID Connect.

As John noted, it is perfectly fine to chain the external authentication and the internal authorization. It is often done. It is just that the RFC6749 Authz server is an RP of OpenID Connect or SP of SAML. Nothing precludes it.

If you really want to avoid the front channel re-auth with prompt=none, which is more secure and proper ways to do, but just to make sure that the user still exists in the authentication service, you can infer it by making a userinfo request to the userinfo endpoint of OpenID Connect. It would fail in various reasons, but would certainly fail if the user does not exist anymore. Other error conditions like the user revoked the access/refresh token etc. would cause the same invalid_token error though.

Best,

Nat

P.S. I do not see why the RFCs you sited are relevant here. I guess you are talking about RFC7521-7523 ;-)

RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC7252 The Constrained Application Protocol (CoAP)
RFC7253 The OCB Authenticated-Encryption Algorithm







2016幎4月20日(æ°Ž) 5:34 Fregly, Andrew <***@verisign.com<mailto:***@verisign.com>>:
Thanks for your reply Nat.

Does your approach match with an IETF OAuth RFC or Draft describing how an Authorization Service can accept and verify an authentication token provided by a client during the authorization process? If so, please point me to that. The only RFCs I have seen that address this are RFCs 7251, 7252 and 7253, and they all have a requirement that an “audience” claim corresponding to the Authorization Service is in the authentication token. Getting that claim into an authentication token provided by an Organization’s Identity provider seems to be my fundamental problem.

Thanks,
Andy

From: Nat Sakimura <***@gmail.com<mailto:***@gmail.com>>
Date: Tuesday, April 19, 2016 at 4:13 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

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 <***@verisign.com<mailto:***@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.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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 <***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

For people using RFC 7521, 7522, 7523 they are taking an assertion and using a WS-* STS to transform it into one with the correct audience to use in 7521.

I know that some people have just ignored the audience, however that can have negative security consequences. When exchanging the token you want to be certain that it is the entity that the token was issued to that is exchanging it.

The STS for the rest of us is a more general framework that should allow you to take a id_token or SAML assertion and securely exchange it for another assertion or access token.

I don’t understand the use case enough to say if that is the best thing for you, but yes that is the intent of that spec.

John B.

Post by Fregly, Andrew
Thank you again of your input Nat.
First of all, I apologize for confusing the situation by referencing the wrong RFCs in a prior email. I transposed two digits. The RFCs I meant to reference where 7521-7523 (see below).
"The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.”
In our use case, we need to have users authenticated against identity providers that organizations use internally as the means for authenticating clients accessing our service. We need this because we believe this is the best means for proving a user is still a member of an organization at the time they authenticate. Most, perhaps all of these organizations, will internally use an Identity Provider that provides SAML authentication assertions. This led me to looking for a way to use authentication tokens produced by internal Identity Providers as a means for proving a client had been authenticated by the organization. A bit of investigation in how this might be done led me to OAuth RFCs 7521, 7522 and 7523. They almost get me there. They specify what needs to be in an Authentication token that is given by a client to an Authorization Service. The gotcha was that these RFCs require an audience claim in the authentication token. This audience claim is used to identify the specific Authorization Service the token is meant for. For this audience claim to get filled in by some arbitrary organization’s Identity Provider, it seems the Identity Provider will need to be told who the Authorization Service is by the client initiating the authentication. I have therefore been looking for a standard that specifies how a client can tell the Identity Provider the identity of the Authorization Service. I was stuck for a bit on how the IETF OAuth working group could address this issue since authentication seemed to be out of scope for the group. Then I found the IETF draft "OAuth 2.0 Token Exchange: An STS for the REST of Us”. It defines a mechanism for telling a Security Token Service the audience for the token it is being asked to issue. I thought that would solve my problem since an intent of the draft seemed to be on generalizing the described approach to any type of Security Token Service. There was one gotcha in the draft though. It limited the type of STS to which the protocol applied to be just Authorization Services. For my use case, I needed the capability described in the draft, but applicable to Identity Providers too. If it were applicable to Identity Providers, there would then be a full set of existing RFCs and drafts that covered the functionality needed for our use case.
Write extensions to RFCs 7521, 7522 and 7523 that eliminate the need for an audience claim in the authentication token if the Authorization Service has a trust relationship with the Identity Provider that issued the authentication token.
Ask the authors of the “OAuth 2.0 Token Exchange: An STS for the REST of Us” to explicitly state that the the approach described there-in is applicable to both Identity Providers and Authorization services.
Before doing either of these steps, I want to make sure that I am not missing something in existing RFCs and drafts that would address our use case. I have only been looking at this issue for a few weeks, so I thought it would be best to go to the experts to get advice. This led to this email chain.
Thanks to all following this chain for your time and consideration on this!
Andy
Date: Tuesday, April 19, 2016 at 5:35 PM
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

Post by Nat Sakimura
Hi Andrew,
In OAuth 2.0, the resource owner authentication /end user authentication is out of scope. What it deals with is "client authentication". They should not be mixed up. There is no end user identity nor authentication token in the OAuth. You cannot do end user authentication with pure OAuth. For that, you have to rely on something like OpenID Connect.
As John noted, it is perfectly fine to chain the external authentication and the internal authorization. It is often done. It is just that the RFC6749 Authz server is an RP of OpenID Connect or SP of SAML. Nothing precludes it.
If you really want to avoid the front channel re-auth with prompt=none, which is more secure and proper ways to do, but just to make sure that the user still exists in the authentication service, you can infer it by making a userinfo request to the userinfo endpoint of OpenID Connect. It would fail in various reasons, but would certainly fail if the user does not exist anymore. Other error conditions like the user revoked the access/refresh token etc. would cause the same invalid_token error though.
Best,
Nat
P.S. I do not see why the RFCs you sited are relevant here. I guess you are talking about RFC7521-7523 ;-)
RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC7252 The Constrained Application Protocol (CoAP)
RFC7253 The OCB Authenticated-Encryption Algorithm

Post by Fregly, Andrew
Thanks for your reply Nat.
Does your approach match with an IETF OAuth RFC or Draft describing how an Authorization Service can accept and verify an authentication token provided by a client during the authorization process? If so, please point me to that. The only RFCs I have seen that address this are RFCs 7251, 7252 and 7253, and they all have a requirement that an “audience” claim corresponding to the Authorization Service is in the authentication token. Getting that claim into an authentication token provided by an Organization’s Identity provider seems to be my fundamental problem.
Thanks,
Andy
Date: Tuesday, April 19, 2016 at 4:13 PM
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

Post by Fregly, Andrew
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?

Post by Fregly, Andrew
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 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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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

Post by John Bradley
Looking at OpenID Connect and it’s trust model for producing id_tokens that assert identity may help you.
http://openid.net/wg/connect/ <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.

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
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[George Fletcher]

So if I understand this correctly, what is really required is a
verifiable claim that the user is still a member of SomeOrg Inc. OpenID
Connect supports both distributed and aggregated claims that can be
signed by the appropriate Identity Provider. The point being that I'm
not sure an "authentication token" is required for this use case to
succeed, it's just one kind of token that can be used.

Also, is the expected flow that the user will first go to the data
provider and then be directed else where from there? If that is the
case, the data provider can just be an OpenID Connect relying party and
give the user an option of the list of supported IdPs to choose from.
The user will then be redirected to SomeOrg Inc. IdP, authenticate and
the data provider will have the authorization and recent authentication
they can validate.

Is the user/data flow more complicated than this?

Thanks,
George

Post by Fregly, Andrew
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
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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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.

Post by Fregly, Andrew
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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Fregly, Andrew]

Thank you for your response George. It points me to some more research to do, such as looking at OpenID Connect support for both distributed and aggregated claims.

Below are replies to your questions/assertions based on my current understanding of the various protocols. Further research and advice will likely enrich this significantly.

Yes, what is required is a verifiable claim that the user is still a member of SomeOrg Inc. I have been operating under the assumption that the only way this can be done would be to have the user authenticated by the Identity Provider for SomeOrg. Perhaps the research into OpenID Connect support for distributed and aggregated claims will reveal an alternative. I foresee a challenge in dealing with Identity Provider’s for organizations using SAML assertions on top of Active Directory and LDAP, and which are not going to do any updating to support our needs.

We do not expect the user to first go to the data provider. We anticipate that the client application would provide a Authentication Token to an Authorization Service service that then issues to the client an access token that the data provider will trust. One of our reasons for doing it this way is that we are trying to eliminate redirects to ease implementation of a native client. We are therefore requiring the client to handle authentication with the Identity Provider as a separate step from authorization.

It might help if I clarified that Verisign’s role in the scenario I described is to be just one of many data providers.

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

So if I understand this correctly, what is really required is a verifiable claim that the user is still a member of SomeOrg Inc. OpenID Connect supports both distributed and aggregated claims that can be signed by the appropriate Identity Provider. The point being that I'm not sure an "authentication token" is required for this use case to succeed, it's just one kind of token that can be used.

Also, is the expected flow that the user will first go to the data provider and then be directed else where from there? If that is the case, the data provider can just be an OpenID Connect relying party and give the user an option of the list of supported IdPs to choose from. The user will then be redirected to SomeOrg Inc. IdP, authenticate and the data provider will have the authorization and recent authentication they can validate.

Is the user/data flow more complicated than this?

Thanks,
George

On 4/19/16 4:05 PM, Fregly, Andrew 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 <<mailto:***@ve7jtb.com>***@ve7jtb.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <<mailto:***@verisign.com>***@verisign.com<mailto:***@verisign.com>>
Cc: "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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 <***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

I should probably just wait for the diagram... but not wanting to wait... :)

If I understand correctly, the user is going to use a client and the
client will authenticate the user via some IdP using an existing method
(SAML, LDAP (?), OpenID Connect, etc). The desire is to take that
response and in some way present it to an "Authorization Server" which
will validate the "authentication response" and return an access token
for use at the data provider(s).

What if the Authorization Server also took on the role of the OpenID
Connect provider. This could work by having the client start an OpenID
Connect flow with Authorization Server (hints could be provided as to
which IdP the user wants to authenticate at). The AS would look at the
"idp hint" and either start and SP SAML flow, or present UI for
collecting LDAP credentials (I don't recommend this) or chain to any
other proprietary IdP flow. Once the user successfully authenticates
with the correct IdP, the AS will finish the OpenID Connect flow
allowing the client to obtain an access token, refresh token and
id_token. The AS could add to the id_token a claim specifying which IdP
the user used during the authentication processed.

The IdP the user used for authentication could also be encoded in the
access_token (or returned as part of an introspection call).

This way whether the data providers are validating the access_tokens
locally or using introspection they can obtain the IdP the user used and
apply their own authorization rules.

The user is only required to do one authorization flow for the client
that is managed by the Authorization Server.

Thanks,
George

Post by Fregly, Andrew
Thank you for your response George. It points me to some more research
to do, such as looking at OpenID Connect support for both distributed
and aggregated claims.
Below are replies to your questions/assertions based on my current
understanding of the various protocols. Further research and advice
will likely enrich this significantly.
Yes, what is required is a verifiable claim that the user is still a
member of SomeOrg Inc. I have been operating under the assumption that
the only way this can be done would be to have the user authenticated
by the Identity Provider for SomeOrg. Perhaps the research into OpenID
Connect support for distributed and aggregated claims will reveal an
alternative. I foresee a challenge in dealing with Identity Provider’s
for organizations using SAML assertions on top of Active Directory and
LDAP, and which are not going to do any updating to support our needs.
We do not expect the user to first go to the data provider. We
anticipate that the client application would provide a Authentication
Token to an Authorization Service service that then issues to the
client an access token that the data provider will trust. One of our
reasons for doing it this way is that we are trying to eliminate
redirects to ease implementation of a native client. We are therefore
requiring the client to handle authentication with the Identity
Provider as a separate step from authorization.
It might help if I clarified that Verisign’s role in the scenario I
described is to be just one of many data providers.
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
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
So if I understand this correctly, what is really required is a
verifiable claim that the user is still a member of SomeOrg Inc.
OpenID Connect supports both distributed and aggregated claims
that can be signed by the appropriate Identity Provider. The point
being that I'm not sure an "authentication token" is required for
this use case to succeed, it's just one kind of token that can be
used.
Also, is the expected flow that the user will first go to the data
provider and then be directed else where from there? If that is
the case, the data provider can just be an OpenID Connect relying
party and give the user an option of the list of supported IdPs to
choose from. The user will then be redirected to SomeOrg Inc. IdP,
authenticate and the data provider will have the authorization and
recent authentication they can validate.
Is the user/data flow more complicated than this?
Thanks,
George

Post by Fregly, Andrew
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
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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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.

Post by Fregly, Andrew
On Apr 19, 2016, at 1:18 PM, Fregly, Andrew
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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list

[Fregly, Andrew]

Hi George,

You fully captured one of the options we have been contemplating. I didn’t propose this flow because I was looking for a way to solve our our use case based on the existing RFCs and OpenID Connect specifications with minimal new specification required. That led me to the path described in the email response I sent out a little while ago to Nat Sakimura’s response. Please take a look at that email and see what you think.

Given how well stated your summary of our needs was, do you still want me to provide a diagram?

Thanks,
Andy

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

I should probably just wait for the diagram... but not wanting to wait... :)

If I understand correctly, the user is going to use a client and the client will authenticate the user via some IdP using an existing method (SAML, LDAP (?), OpenID Connect, etc). The desire is to take that response and in some way present it to an "Authorization Server" which will validate the "authentication response" and return an access token for use at the data provider(s).

What if the Authorization Server also took on the role of the OpenID Connect provider. This could work by having the client start an OpenID Connect flow with Authorization Server (hints could be provided as to which IdP the user wants to authenticate at). The AS would look at the "idp hint" and either start and SP SAML flow, or present UI for collecting LDAP credentials (I don't recommend this) or chain to any other proprietary IdP flow. Once the user successfully authenticates with the correct IdP, the AS will finish the OpenID Connect flow allowing the client to obtain an access token, refresh token and id_token. The AS could add to the id_token a claim specifying which IdP the user used during the authentication processed.

The IdP the user used for authentication could also be encoded in the access_token (or returned as part of an introspection call).

This way whether the data providers are validating the access_tokens locally or using introspection they can obtain the IdP the user used and apply their own authorization rules.

The user is only required to do one authorization flow for the client that is managed by the Authorization Server.

Thanks,
George

On 4/19/16 5:06 PM, Fregly, Andrew wrote:
Thank you for your response George. It points me to some more research to do, such as looking at OpenID Connect support for both distributed and aggregated claims.

Below are replies to your questions/assertions based on my current understanding of the various protocols. Further research and advice will likely enrich this significantly.

Yes, what is required is a verifiable claim that the user is still a member of SomeOrg Inc. I have been operating under the assumption that the only way this can be done would be to have the user authenticated by the Identity Provider for SomeOrg. Perhaps the research into OpenID Connect support for distributed and aggregated claims will reveal an alternative. I foresee a challenge in dealing with Identity Provider’s for organizations using SAML assertions on top of Active Directory and LDAP, and which are not going to do any updating to support our needs.

We do not expect the user to first go to the data provider. We anticipate that the client application would provide a Authentication Token to an Authorization Service service that then issues to the client an access token that the data provider will trust. One of our reasons for doing it this way is that we are trying to eliminate redirects to ease implementation of a native client. We are therefore requiring the client to handle authentication with the Identity Provider as a separate step from authorization.

It might help if I clarified that Verisign’s role in the scenario I described is to be just one of many data providers.

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
To: Andrew Fregly <<mailto:***@verisign.com>***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

So if I understand this correctly, what is really required is a verifiable claim that the user is still a member of SomeOrg Inc. OpenID Connect supports both distributed and aggregated claims that can be signed by the appropriate Identity Provider. The point being that I'm not sure an "authentication token" is required for this use case to succeed, it's just one kind of token that can be used.

Also, is the expected flow that the user will first go to the data provider and then be directed else where from there? If that is the case, the data provider can just be an OpenID Connect relying party and give the user an option of the list of supported IdPs to choose from. The user will then be redirected to SomeOrg Inc. IdP, authenticate and the data provider will have the authorization and recent authentication they can validate.

Is the user/data flow more complicated than this?

Thanks,
George

On 4/19/16 4:05 PM, Fregly, Andrew 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.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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 <<mailto:***@verisign.com>***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

Hi Andy,

Glad I guessed correctly:) If there are network or other limitations in
how the client gets and uses tokens, that would be helpful in a diagram
sense. As John points out in his response, not having an audience has
possible security implications.

If I'm following your original thinking... it goes something like this...

1. Mobile app asks users to authenticate at "their" IdP
2. Mobile app gets back "authentication token" (likely some sort of SAML
assertion)
3. Mobile app presents "authentication token" to Authorization Service
4. Authorization Service validate "authentication token" and returns an
access_token
5. Mobile app invokes data provider passing the access_token
6. Data provider validates access_token (either locally or via an
introspection endpoint on the AS)

In this flow there are really two tokens: the "authentication token" and
the access_token. There should be an audience for both tokens. The
audience of the "authentication token" should be the AS, and the
audience of the access_token should be the data provider the client is
going to use.

So, if there are no network firewall type limitations, it seems much
simpler to just have the AS use the external IdPs as it's authentication
mechanisms and the rest is just default OpenID Connect. Meaning that the
Mobile app starts an OpenID Connect flow with the AS, the AS get the
user authenticated via the user's IdP, the AS provides access and id
tokens bask to the Mobile app (following the code or other flow).

Am I missing something?

Thanks,
George

Post by Fregly, Andrew
Hi George,
You fully captured one of the options we have been contemplating. I
didn’t propose this flow because I was looking for a way to solve our
our use case based on the existing RFCs and OpenID Connect
specifications with minimal new specification required. That led me to
the path described in the email response I sent out a little while ago
to Nat Sakimura’s response. Please take a look at that email and see
what you think.
Given how well stated your summary of our needs was, do you still want
me to provide a diagram?
Thanks,
Andy
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
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
I should probably just wait for the diagram... but not wanting to wait... :)
If I understand correctly, the user is going to use a client and
the client will authenticate the user via some IdP using an
existing method (SAML, LDAP (?), OpenID Connect, etc). The desire
is to take that response and in some way present it to an
"Authorization Server" which will validate the "authentication
response" and return an access token for use at the data provider(s).
What if the Authorization Server also took on the role of the
OpenID Connect provider. This could work by having the client
start an OpenID Connect flow with Authorization Server (hints
could be provided as to which IdP the user wants to authenticate
at). The AS would look at the "idp hint" and either start and SP
SAML flow, or present UI for collecting LDAP credentials (I don't
recommend this) or chain to any other proprietary IdP flow. Once
the user successfully authenticates with the correct IdP, the AS
will finish the OpenID Connect flow allowing the client to obtain
an access token, refresh token and id_token. The AS could add to
the id_token a claim specifying which IdP the user used during the
authentication processed.
The IdP the user used for authentication could also be encoded in
the access_token (or returned as part of an introspection call).
This way whether the data providers are validating the
access_tokens locally or using introspection they can obtain the
IdP the user used and apply their own authorization rules.
The user is only required to do one authorization flow for the
client that is managed by the Authorization Server.
Thanks,
George

Post by Fregly, Andrew
Thank you for your response George. It points me to some more
research to do, such as looking at OpenID Connect support for
both distributed and aggregated claims.
Below are replies to your questions/assertions based on my
current understanding of the various protocols. Further research
and advice will likely enrich this significantly.
Yes, what is required is a verifiable claim that the user is
still a member of SomeOrg Inc. I have been operating under the
assumption that the only way this can be done would be to have
the user authenticated by the Identity Provider for SomeOrg.
Perhaps the research into OpenID Connect support for distributed
and aggregated claims will reveal an alternative. I foresee a
challenge in dealing with Identity Provider’s for organizations
using SAML assertions on top of Active Directory and LDAP, and
which are not going to do any updating to support our needs.
We do not expect the user to first go to the data provider. We
anticipate that the client application would provide a
Authentication Token to an Authorization Service service that
then issues to the client an access token that the data provider
will trust. One of our reasons for doing it this way is that we
are trying to eliminate redirects to ease implementation of a
native client. We are therefore requiring the client to handle
authentication with the Identity Provider as a separate step from
authorization.
It might help if I clarified that Verisign’s role in the scenario
I described is to be just one of many data providers.
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
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
So if I understand this correctly, what is really required is
a verifiable claim that the user is still a member of SomeOrg
Inc. OpenID Connect supports both distributed and aggregated
claims that can be signed by the appropriate Identity
Provider. The point being that I'm not sure an
"authentication token" is required for this use case to
succeed, it's just one kind of token that can be used.
Also, is the expected flow that the user will first go to the
data provider and then be directed else where from there? If
that is the case, the data provider can just be an OpenID
Connect relying party and give the user an option of the list
of supported IdPs to choose from. The user will then be
redirected to SomeOrg Inc. IdP, authenticate and the data
provider will have the authorization and recent
authentication they can validate.
Is the user/data flow more complicated than this?
Thanks,
George

Post by Fregly, Andrew
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
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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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.

Post by Fregly, Andrew
On Apr 19, 2016, at 1:18 PM, Fregly, Andrew
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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list

[Fregly, Andrew]

All,

I will come up with a considered response to this by tomorrow some time. This interaction has been extremely helpful!

Andy

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 1:36 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

Hi Andy,

Glad I guessed correctly:) If there are network or other limitations in how the client gets and uses tokens, that would be helpful in a diagram sense. As John points out in his response, not having an audience has possible security implications.

If I'm following your original thinking... it goes something like this...

1. Mobile app asks users to authenticate at "their" IdP
2. Mobile app gets back "authentication token" (likely some sort of SAML assertion)
3. Mobile app presents "authentication token" to Authorization Service
4. Authorization Service validate "authentication token" and returns an access_token
5. Mobile app invokes data provider passing the access_token
6. Data provider validates access_token (either locally or via an introspection endpoint on the AS)

In this flow there are really two tokens: the "authentication token" and the access_token. There should be an audience for both tokens. The audience of the "authentication token" should be the AS, and the audience of the access_token should be the data provider the client is going to use.

So, if there are no network firewall type limitations, it seems much simpler to just have the AS use the external IdPs as it's authentication mechanisms and the rest is just default OpenID Connect. Meaning that the Mobile app starts an OpenID Connect flow with the AS, the AS get the user authenticated via the user's IdP, the AS provides access and id tokens bask to the Mobile app (following the code or other flow).

Am I missing something?

Thanks,
George

On 4/20/16 10:31 AM, Fregly, Andrew wrote:
Hi George,

You fully captured one of the options we have been contemplating. I didn’t propose this flow because I was looking for a way to solve our our use case based on the existing RFCs and OpenID Connect specifications with minimal new specification required. That led me to the path described in the email response I sent out a little while ago to Nat Sakimura’s response. Please take a look at that email and see what you think.

Given how well stated your summary of our needs was, do you still want me to provide a diagram?

Thanks,
Andy

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
To: Andrew Fregly <<mailto:***@verisign.com>***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

I should probably just wait for the diagram... but not wanting to wait... :)

If I understand correctly, the user is going to use a client and the client will authenticate the user via some IdP using an existing method (SAML, LDAP (?), OpenID Connect, etc). The desire is to take that response and in some way present it to an "Authorization Server" which will validate the "authentication response" and return an access token for use at the data provider(s).

What if the Authorization Server also took on the role of the OpenID Connect provider. This could work by having the client start an OpenID Connect flow with Authorization Server (hints could be provided as to which IdP the user wants to authenticate at). The AS would look at the "idp hint" and either start and SP SAML flow, or present UI for collecting LDAP credentials (I don't recommend this) or chain to any other proprietary IdP flow. Once the user successfully authenticates with the correct IdP, the AS will finish the OpenID Connect flow allowing the client to obtain an access token, refresh token and id_token. The AS could add to the id_token a claim specifying which IdP the user used during the authentication processed.

The IdP the user used for authentication could also be encoded in the access_token (or returned as part of an introspection call).

This way whether the data providers are validating the access_tokens locally or using introspection they can obtain the IdP the user used and apply their own authorization rules.

The user is only required to do one authorization flow for the client that is managed by the Authorization Server.

Thanks,
George

On 4/19/16 5:06 PM, Fregly, Andrew wrote:
Thank you for your response George. It points me to some more research to do, such as looking at OpenID Connect support for both distributed and aggregated claims.

Below are replies to your questions/assertions based on my current understanding of the various protocols. Further research and advice will likely enrich this significantly.

Yes, what is required is a verifiable claim that the user is still a member of SomeOrg Inc. I have been operating under the assumption that the only way this can be done would be to have the user authenticated by the Identity Provider for SomeOrg. Perhaps the research into OpenID Connect support for distributed and aggregated claims will reveal an alternative. I foresee a challenge in dealing with Identity Provider’s for organizations using SAML assertions on top of Active Directory and LDAP, and which are not going to do any updating to support our needs.

We do not expect the user to first go to the data provider. We anticipate that the client application would provide a Authentication Token to an Authorization Service service that then issues to the client an access token that the data provider will trust. One of our reasons for doing it this way is that we are trying to eliminate redirects to ease implementation of a native client. We are therefore requiring the client to handle authentication with the Identity Provider as a separate step from authorization.

It might help if I clarified that Verisign’s role in the scenario I described is to be just one of many data providers.

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

So if I understand this correctly, what is really required is a verifiable claim that the user is still a member of SomeOrg Inc. OpenID Connect supports both distributed and aggregated claims that can be signed by the appropriate Identity Provider. The point being that I'm not sure an "authentication token" is required for this use case to succeed, it's just one kind of token that can be used.

Also, is the expected flow that the user will first go to the data provider and then be directed else where from there? If that is the case, the data provider can just be an OpenID Connect relying party and give the user an option of the list of supported IdPs to choose from. The user will then be redirected to SomeOrg Inc. IdP, authenticate and the data provider will have the authorization and recent authentication they can validate.

Is the user/data flow more complicated than this?

Thanks,
George

On 4/19/16 4:05 PM, Fregly, Andrew 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.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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/>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 <<mailto:***@verisign.com>***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>https://www.ietf.org/mailman/listinfo/oauth

[Fregly, Andrew]

Hi George,

You have the flow right for how I have been approaching the problem. Note that the client doesn’t have to be a mobile app, but that represents well what we are trying to solve. Per your recommendation, what I am missing in my knowledge is a standard for how the AS could be directed to use an external IdP for authentication. Not knowing this, I have been assuming the flow you described as my “original thinking" would be required. I will do some more research on the topic and check back in.

Thanks,
Andy


From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 1:36 PM
To: "Fregly, Andrew" <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

Hi Andy,

Glad I guessed correctly:) If there are network or other limitations in how the client gets and uses tokens, that would be helpful in a diagram sense. As John points out in his response, not having an audience has possible security implications.

If I'm following your original thinking... it goes something like this...

1. Mobile app asks users to authenticate at "their" IdP
2. Mobile app gets back "authentication token" (likely some sort of SAML assertion)
3. Mobile app presents "authentication token" to Authorization Service
4. Authorization Service validate "authentication token" and returns an access_token
5. Mobile app invokes data provider passing the access_token
6. Data provider validates access_token (either locally or via an introspection endpoint on the AS)

In this flow there are really two tokens: the "authentication token" and the access_token. There should be an audience for both tokens. The audience of the "authentication token" should be the AS, and the audience of the access_token should be the data provider the client is going to use.

So, if there are no network firewall type limitations, it seems much simpler to just have the AS use the external IdPs as it's authentication mechanisms and the rest is just default OpenID Connect. Meaning that the Mobile app starts an OpenID Connect flow with the AS, the AS get the user authenticated via the user's IdP, the AS provides access and id tokens bask to the Mobile app (following the code or other flow).

Am I missing something?

Thanks,
George

On 4/20/16 10:31 AM, Fregly, Andrew wrote:
Hi George,

You fully captured one of the options we have been contemplating. I didn’t propose this flow because I was looking for a way to solve our our use case based on the existing RFCs and OpenID Connect specifications with minimal new specification required. That led me to the path described in the email response I sent out a little while ago to Nat Sakimura’s response. Please take a look at that email and see what you think.

Given how well stated your summary of our needs was, do you still want me to provide a diagram?

Thanks,
Andy

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
To: Andrew Fregly <<mailto:***@verisign.com>***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

I should probably just wait for the diagram... but not wanting to wait... :)

If I understand correctly, the user is going to use a client and the client will authenticate the user via some IdP using an existing method (SAML, LDAP (?), OpenID Connect, etc). The desire is to take that response and in some way present it to an "Authorization Server" which will validate the "authentication response" and return an access token for use at the data provider(s).

What if the Authorization Server also took on the role of the OpenID Connect provider. This could work by having the client start an OpenID Connect flow with Authorization Server (hints could be provided as to which IdP the user wants to authenticate at). The AS would look at the "idp hint" and either start and SP SAML flow, or present UI for collecting LDAP credentials (I don't recommend this) or chain to any other proprietary IdP flow. Once the user successfully authenticates with the correct IdP, the AS will finish the OpenID Connect flow allowing the client to obtain an access token, refresh token and id_token. The AS could add to the id_token a claim specifying which IdP the user used during the authentication processed.

The IdP the user used for authentication could also be encoded in the access_token (or returned as part of an introspection call).

This way whether the data providers are validating the access_tokens locally or using introspection they can obtain the IdP the user used and apply their own authorization rules.

The user is only required to do one authorization flow for the client that is managed by the Authorization Server.

Thanks,
George

On 4/19/16 5:06 PM, Fregly, Andrew wrote:
Thank you for your response George. It points me to some more research to do, such as looking at OpenID Connect support for both distributed and aggregated claims.

Below are replies to your questions/assertions based on my current understanding of the various protocols. Further research and advice will likely enrich this significantly.

Yes, what is required is a verifiable claim that the user is still a member of SomeOrg Inc. I have been operating under the assumption that the only way this can be done would be to have the user authenticated by the Identity Provider for SomeOrg. Perhaps the research into OpenID Connect support for distributed and aggregated claims will reveal an alternative. I foresee a challenge in dealing with Identity Provider’s for organizations using SAML assertions on top of Active Directory and LDAP, and which are not going to do any updating to support our needs.

We do not expect the user to first go to the data provider. We anticipate that the client application would provide a Authentication Token to an Authorization Service service that then issues to the client an access token that the data provider will trust. One of our reasons for doing it this way is that we are trying to eliminate redirects to ease implementation of a native client. We are therefore requiring the client to handle authentication with the Identity Provider as a separate step from authorization.

It might help if I clarified that Verisign’s role in the scenario I described is to be just one of many data providers.

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

So if I understand this correctly, what is really required is a verifiable claim that the user is still a member of SomeOrg Inc. OpenID Connect supports both distributed and aggregated claims that can be signed by the appropriate Identity Provider. The point being that I'm not sure an "authentication token" is required for this use case to succeed, it's just one kind of token that can be used.

Also, is the expected flow that the user will first go to the data provider and then be directed else where from there? If that is the case, the data provider can just be an OpenID Connect relying party and give the user an option of the list of supported IdPs to choose from. The user will then be redirected to SomeOrg Inc. IdP, authenticate and the data provider will have the authorization and recent authentication they can validate.

Is the user/data flow more complicated than this?

Thanks,
George

On 4/19/16 4:05 PM, Fregly, Andrew 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.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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/>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 <<mailto:***@verisign.com>***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

OpenID Connect defines a third-party login endpoint for RP's, which is
what the AS is acting as in this case:

http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin

-- Justin

Post by Fregly, Andrew
Hi George,
You have the flow right for how I have been approaching the problem.
Note that the client doesn’t have to be a mobile app, but that
represents well what we are trying to solve. Per your recommendation,
what I am missing in my knowledge is a standard for how the AS could
be directed to use an external IdP for authentication. Not knowing
this, I have been assuming the flow you described as my “original
thinking" would be required. I will do some more research on the topic
and check back in.
Thanks,
Andy
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 1:36 PM
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
Hi Andy,
Glad I guessed correctly:) If there are network or other limitations
in how the client gets and uses tokens, that would be helpful in a
diagram sense. As John points out in his response, not having an
audience has possible security implications.
If I'm following your original thinking... it goes something like this...
1. Mobile app asks users to authenticate at "their" IdP
2. Mobile app gets back "authentication token" (likely some sort of SAML assertion)
3. Mobile app presents "authentication token" to Authorization Service
4. Authorization Service validate "authentication token" and returns an access_token
5. Mobile app invokes data provider passing the access_token
6. Data provider validates access_token (either locally or via an
introspection endpoint on the AS)
In this flow there are really two tokens: the "authentication token"
and the access_token. There should be an audience for both tokens. The
audience of the "authentication token" should be the AS, and the
audience of the access_token should be the data provider the client is
going to use.
So, if there are no network firewall type limitations, it seems much
simpler to just have the AS use the external IdPs as it's
authentication mechanisms and the rest is just default OpenID Connect.
Meaning that the Mobile app starts an OpenID Connect flow with the AS,
the AS get the user authenticated via the user's IdP, the AS provides
access and id tokens bask to the Mobile app (following the code or
other flow).
Am I missing something?
Thanks,
George

Post by Fregly, Andrew
Hi George,
You fully captured one of the options we have been contemplating. I
didn’t propose this flow because I was looking for a way to solve our
our use case based on the existing RFCs and OpenID Connect
specifications with minimal new specification required. That led me
to the path described in the email response I sent out a little while
ago to Nat Sakimura’s response. Please take a look at that email and
see what you think.
Given how well stated your summary of our needs was, do you still
want me to provide a diagram?
Thanks,
Andy
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
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
I should probably just wait for the diagram... but not wanting to wait... :)
If I understand correctly, the user is going to use a client and
the client will authenticate the user via some IdP using an
existing method (SAML, LDAP (?), OpenID Connect, etc). The desire
is to take that response and in some way present it to an
"Authorization Server" which will validate the "authentication
response" and return an access token for use at the data provider(s).
What if the Authorization Server also took on the role of the
OpenID Connect provider. This could work by having the client
start an OpenID Connect flow with Authorization Server (hints
could be provided as to which IdP the user wants to authenticate
at). The AS would look at the "idp hint" and either start and SP
SAML flow, or present UI for collecting LDAP credentials (I don't
recommend this) or chain to any other proprietary IdP flow. Once
the user successfully authenticates with the correct IdP, the AS
will finish the OpenID Connect flow allowing the client to obtain
an access token, refresh token and id_token. The AS could add to
the id_token a claim specifying which IdP the user used during
the authentication processed.
The IdP the user used for authentication could also be encoded in
the access_token (or returned as part of an introspection call).
This way whether the data providers are validating the
access_tokens locally or using introspection they can obtain the
IdP the user used and apply their own authorization rules.
The user is only required to do one authorization flow for the
client that is managed by the Authorization Server.
Thanks,
George

Post by Fregly, Andrew
Thank you for your response George. It points me to some more
research to do, such as looking at OpenID Connect support for
both distributed and aggregated claims.
Below are replies to your questions/assertions based on my
current understanding of the various protocols. Further research
and advice will likely enrich this significantly.
Yes, what is required is a verifiable claim that the user is
still a member of SomeOrg Inc. I have been operating under the
assumption that the only way this can be done would be to have
the user authenticated by the Identity Provider for SomeOrg.
Perhaps the research into OpenID Connect support for distributed
and aggregated claims will reveal an alternative. I foresee a
challenge in dealing with Identity Provider’s for organizations
using SAML assertions on top of Active Directory and LDAP, and
which are not going to do any updating to support our needs.
We do not expect the user to first go to the data provider. We
anticipate that the client application would provide a
Authentication Token to an Authorization Service service that
then issues to the client an access token that the data provider
will trust. One of our reasons for doing it this way is that we
are trying to eliminate redirects to ease implementation of a
native client. We are therefore requiring the client to handle
authentication with the Identity Provider as a separate step
from authorization.
It might help if I clarified that Verisign’s role in the
scenario I described is to be just one of many data providers.
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
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
So if I understand this correctly, what is really required
is a verifiable claim that the user is still a member of
SomeOrg Inc. OpenID Connect supports both distributed and
aggregated claims that can be signed by the appropriate
Identity Provider. The point being that I'm not sure an
"authentication token" is required for this use case to
succeed, it's just one kind of token that can be used.
Also, is the expected flow that the user will first go to
the data provider and then be directed else where from
there? If that is the case, the data provider can just be an
OpenID Connect relying party and give the user an option of
the list of supported IdPs to choose from. The user will
then be redirected to SomeOrg Inc. IdP, authenticate and the
data provider will have the authorization and recent
authentication they can validate.
Is the user/data flow more complicated than this?
Thanks,
George

Post by Fregly, Andrew
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
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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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.

Post by Fregly, Andrew
On Apr 19, 2016, at 1:18 PM, Fregly, Andrew
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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list

--
Chief Architect
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter:http://twitter.com/gffletch
Office: [phone] Photos:http://georgefletcher.photography
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Fregly, Andrew]

Thank you for that link Justin. The approach you mentioned would work well if we were dealing with an all OpenID Connect world. I don’t think it will work for our requirements. We need to support authentication with the legacy Identity Providers found within organizations from client types that might be native apps as well as Web clients. We can’t put in any requirements that require changes to the Identity Providers, such as requiring them to handle redirects in accordance with OAuth or OpenID Connect standards. The advice and direction I have received from this group has been very useful in pointing me to the various approaches that needed to be considered. After considering all that I have learned, I think our use case is out of the design constraints that have been driving the development of OAuth and OpenID Connect. Despite that, I can get very close with the existing OAuth RFCs. This may result in me writing a draft/profile that describes what was needed on top of those RFCs and a discussion of the security implications of the additions. If anybody would like to follow up with me, please email me directly as I don’t know if it is worth beating on this topic any more with the full group.

From: Justin Richer <***@mit.edu<mailto:***@mit.edu>>
Date: Saturday, April 23, 2016 at 9:55 AM
To: "Fregly, Andrew" <***@verisign.com<mailto:***@verisign.com>>, George Fletcher <***@aol.com<mailto:***@aol.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

OpenID Connect defines a third-party login endpoint for RP's, which is what the AS is acting as in this case:

http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin

-- Justin

On 4/22/2016 10:50 AM, Fregly, Andrew wrote:
Hi George,

You have the flow right for how I have been approaching the problem. Note that the client doesn’t have to be a mobile app, but that represents well what we are trying to solve. Per your recommendation, what I am missing in my knowledge is a standard for how the AS could be directed to use an external IdP for authentication. Not knowing this, I have been assuming the flow you described as my “original thinking" would be required. I will do some more research on the topic and check back in.

Thanks,
Andy


From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 1:36 PM
To: "Fregly, Andrew" <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

Hi Andy,

Glad I guessed correctly:) If there are network or other limitations in how the client gets and uses tokens, that would be helpful in a diagram sense. As John points out in his response, not having an audience has possible security implications.

If I'm following your original thinking... it goes something like this...

1. Mobile app asks users to authenticate at "their" IdP
2. Mobile app gets back "authentication token" (likely some sort of SAML assertion)
3. Mobile app presents "authentication token" to Authorization Service
4. Authorization Service validate "authentication token" and returns an access_token
5. Mobile app invokes data provider passing the access_token
6. Data provider validates access_token (either locally or via an introspection endpoint on the AS)

In this flow there are really two tokens: the "authentication token" and the access_token. There should be an audience for both tokens. The audience of the "authentication token" should be the AS, and the audience of the access_token should be the data provider the client is going to use.

So, if there are no network firewall type limitations, it seems much simpler to just have the AS use the external IdPs as it's authentication mechanisms and the rest is just default OpenID Connect. Meaning that the Mobile app starts an OpenID Connect flow with the AS, the AS get the user authenticated via the user's IdP, the AS provides access and id tokens bask to the Mobile app (following the code or other flow).

Am I missing something?

Thanks,
George

On 4/20/16 10:31 AM, Fregly, Andrew wrote:
Hi George,

You fully captured one of the options we have been contemplating. I didn’t propose this flow because I was looking for a way to solve our our use case based on the existing RFCs and OpenID Connect specifications with minimal new specification required. That led me to the path described in the email response I sent out a little while ago to Nat Sakimura’s response. Please take a look at that email and see what you think.

Given how well stated your summary of our needs was, do you still want me to provide a diagram?

Thanks,
Andy

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

I should probably just wait for the diagram... but not wanting to wait... :)

If I understand correctly, the user is going to use a client and the client will authenticate the user via some IdP using an existing method (SAML, LDAP (?), OpenID Connect, etc). The desire is to take that response and in some way present it to an "Authorization Server" which will validate the "authentication response" and return an access token for use at the data provider(s).

What if the Authorization Server also took on the role of the OpenID Connect provider. This could work by having the client start an OpenID Connect flow with Authorization Server (hints could be provided as to which IdP the user wants to authenticate at). The AS would look at the "idp hint" and either start and SP SAML flow, or present UI for collecting LDAP credentials (I don't recommend this) or chain to any other proprietary IdP flow. Once the user successfully authenticates with the correct IdP, the AS will finish the OpenID Connect flow allowing the client to obtain an access token, refresh token and id_token. The AS could add to the id_token a claim specifying which IdP the user used during the authentication processed.

The IdP the user used for authentication could also be encoded in the access_token (or returned as part of an introspection call).

This way whether the data providers are validating the access_tokens locally or using introspection they can obtain the IdP the user used and apply their own authorization rules.

The user is only required to do one authorization flow for the client that is managed by the Authorization Server.

Thanks,
George

On 4/19/16 5:06 PM, Fregly, Andrew wrote:
Thank you for your response George. It points me to some more research to do, such as looking at OpenID Connect support for both distributed and aggregated claims.

Below are replies to your questions/assertions based on my current understanding of the various protocols. Further research and advice will likely enrich this significantly.

Yes, what is required is a verifiable claim that the user is still a member of SomeOrg Inc. I have been operating under the assumption that the only way this can be done would be to have the user authenticated by the Identity Provider for SomeOrg. Perhaps the research into OpenID Connect support for distributed and aggregated claims will reveal an alternative. I foresee a challenge in dealing with Identity Provider’s for organizations using SAML assertions on top of Active Directory and LDAP, and which are not going to do any updating to support our needs.

We do not expect the user to first go to the data provider. We anticipate that the client application would provide a Authentication Token to an Authorization Service service that then issues to the client an access token that the data provider will trust. One of our reasons for doing it this way is that we are trying to eliminate redirects to ease implementation of a native client. We are therefore requiring the client to handle authentication with the Identity Provider as a separate step from authorization.

It might help if I clarified that Verisign’s role in the scenario I described is to be just one of many data providers.

From: George Fletcher <***@aol.com<mailto:***@aol.com>>
Organization: AOL LLC
Date: Tuesday, April 19, 2016 at 4:18 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

So if I understand this correctly, what is really required is a verifiable claim that the user is still a member of SomeOrg Inc. OpenID Connect supports both distributed and aggregated claims that can be signed by the appropriate Identity Provider. The point being that I'm not sure an "authentication token" is required for this use case to succeed, it's just one kind of token that can be used.

Also, is the expected flow that the user will first go to the data provider and then be directed else where from there? If that is the case, the data provider can just be an OpenID Connect relying party and give the user an option of the list of supported IdPs to choose from. The user will then be redirected to SomeOrg Inc. IdP, authenticate and the data provider will have the authorization and recent authentication they can validate.

Is the user/data flow more complicated than this?

Thanks,
George

On 4/19/16 4:05 PM, Fregly, Andrew 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 <<mailto:***@ve7jtb.com>***@ve7jtb.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <<mailto:***@verisign.com>***@verisign.com<mailto:***@verisign.com>>
Cc: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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/>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 <<mailto:***@verisign.com>***@verisign.com<mailto:***@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
<mailto:***@ietf.org>***@ietf.org<mailto:***@ietf.org>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work: ***@teamaol.com<mailto:***@teamaol.com>
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter: http://twitter.com/gffletch
Office: [phone] Photos: http://georgefletcher.photography



_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

You can use connect just as a authentication service as you would SAML.

Lots of SaaS providers have a authorization service that chains to a external authentication service via SAML or Connect by use of a browser.

I am not getting what is front channel with the user and what is back channel.

Is the user authenticating with the service that provides the role info, or are you trying to do that in the back channel via a token exchange.

I probably need a diagram.

John B.

Post by Fregly, Andrew
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 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.
Date: Tuesday, April 19, 2016 at 2:06 PM
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

Post by John Bradley
Looking at OpenID Connect and it’s trust model for producing id_tokens that assert identity may help you.
http://openid.net/wg/connect/ <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.

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
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[Fregly, Andrew]

Thanks John! I will provide a diagram tomorrow.

Andy

From: John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 4:27 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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

You can use connect just as a authentication service as you would SAML.

Lots of SaaS providers have a authorization service that chains to a external authentication service via SAML or Connect by use of a browser.

I am not getting what is front channel with the user and what is back channel.

Is the user authenticating with the service that provides the role info, or are you trying to do that in the back channel via a token exchange.

I probably need a diagram.

John B.
On Apr 19, 2016, at 5:05 PM, Fregly, Andrew <***@verisign.com<mailto:***@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.com<mailto:***@ve7jtb.com>>
Date: Tuesday, April 19, 2016 at 2:06 PM
To: Andrew Fregly <***@verisign.com<mailto:***@verisign.com>>
Cc: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@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 <***@verisign.com<mailto:***@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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth