Phil,
My comments are in-line too.
inline...
Phil
Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Aug 1, 2017, at 12:56 PM, Denis <denis.i...@free.fr
<mailto:denis.i...@free.fr>> wrote:
Phil,
Originally, with OAuth the AS and the RS were co-located. Many
additional RFCs made extensions and this assumption is no more valid.
draft-ietf-oauth-token-exchange-09 is now opening a pandora box where
an even more complex situation is envisaged (without explicitly
stating it)
there would be one client, one RS and several AS/STS with
relationships between AS/STS from different domains (don't ask me
what a domain
might mean in this context).
I don’t think that is true. It allows a resource server to act on
behalf of the user further on down the line. The user context is
already well known.
The draft is saying on page 4:
An OAuth resource server, for example, might assume
the role of the client during token exchange in order to trade an
access token, which it received in a protected resource request, for
a new token that is appropriate to include in a call to a backend
service.
This means that a token received from one AS/STS will be sent to another
AS/STS in order to get a new access token from the second AS/STS.
This means several AS/STS with relationships between AS/STS from
different "domains" as I wrote.
As always, it can be mis-used. Maybe there is an argument for more
guidance?
See my other post about privacy in the case where a single AS/STS is
involved in a transaction. It is under the following topic :
How could an IdP create an id token for one audience RP without
knowing for which RP ?
The topic was raised at the last OAuth Workshop in Zürich by a
student from ETH Zürich.
In OIDC, the audience is *always* the client. If you are grabbing an
ID Token to then relay it to another RP, then you are into a
dual-audience thing which is doable but falls outside the
specifications AFAIK.
The complex case you are mentioning is fairly different from the basic
case I am considering. In the basic case, there is one client, one RP
and one AS/STS.
This is the case I am considering and for which I believe we need a
solution. Up to now, when using JWTs, if a JWT is targeted, it allows
the AS/STS
to act as Big Brother and there is no other alternative. It is a "*Big
Brother by design*" solution instead of a "*Privacy by Design*" solution.
I have seen a lot of bad patterns where mobile clients are getting ID
Tokens and simply passing them on to a resource server.
The resource server cannot validate the audience leading to all sorts
of problem. A better method is the AppAuth pattern.
In OAuth there is currently no RFC which provides a response to that
question. A specification based on OAuth, OpenID Connect,
is using the concept of an IdP (Identity Provider). Currently, since
there is no standardized way to address this concern, any IdP will be
able
to act as Big Brother: it will know where the access tokens will be
used. So tracking the activities of the clients will be straightforward.
So the way forward might be to put forward an individual draft and see
if anyone in the WG wants to work on it in a future charter?
Before writing an individual draft, there needs to be a general
agreement within the WG to consider such a work item as valuable.
Addressing the same question when multiple AS/STS would be involved
should only be discussed, once we a solution is defined
in the case where a single AS/STS is involved. Before doing this, we
would need to define an architecture.
10 years ago, the IETF was only dealing with security considerations.
Nowadays, it also has to deal with privacy considerations.
This seems like an argument for new work.
Indeed.
Denis
Denis
Denis,
Why is privacy a concern? OAuth is designed to have the
Authorization Server be the issuer of tokens for a specific set of
resource servers. The AS represents users on the Resource server.
It does not represent users of the client - though they are often
the same physical person, they are often different authenticated
subjects.
Of course, there are profiles of OAuth which change this
relationship, but the foundational assumption in RFC6749 is the AS
is usually associated with the RS.
Phil
Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=k0OcooLpewsIZuo4PrVKJp0Xj6JCTKqIrgYUuBohzsg&e=>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Aug 1, 2017, at 3:53 AM, Denis <denis.i...@free.fr
<mailto:denis.i...@free.fr>> wrote:
Hello Brian,
I don't think that's what I'm saying. Some of these concepts are
difficult to reason about on a mailing list so I apologize for any
miss or poor communication.
When requesting a token, the resource or audience parameter can be
used to indicate the target service where the client intends to
use the token that it is requesting. Audience is a logical name
that says where the client wants to use the requested token. As a
a logical name, the parties involved do need to know about the
name. The resource parameter lets the client indicate to the
AS/STS where it intends to use the issued token by providing the
location, typically as an https URL, in the token exchange request
in the same form that will be used to access that resource (again,
an HTTPS URL). And the resource URL or audience can certinally
indicate something that's external. Those parameters allow the
AS/STS to determine where the token is going to be used (including
externally) and produce the the appropriate token for that target
based on configuration and policy. The text
inhttps://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D2.1&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=t81PcW8OeakhXWTN4taxK-3GjGymFNaG965TL1qLIh8&e=>about
those parameters attempts to describe that in an intelligible way.
Though there's likely always room for improvement.
Bear in mind, that they are cases where privacy is a concern, and
for these cases the resource or audience parameter*cannot*be used
to indicate the target service where the client intends to use the
token that it is requesting.
In general OAuth, the structure, content, style, etc. of access
tokens is not defined. That stuff has to be agreed on between the
AS and RS.
RFC 7515 defines the major fields of a JWT.
Although Token Introspection (RFC 7662)
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7662&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=WDhJlyoSgBPPRU2hhQdG2Q1f5ex2GlBwRkIaeMhOsl8&e=>has
since been defined to give a more standardized option for the RS
to query the AS for status and meta-information about an access
token. Even with introspection, however, an RS effectively can
only use access tokens from one AS because there's nothing
standard provided by OAuth to indicate where the token is from
when it's presented to the RS.
RFC 7515 defines the "x5c" (X.509 Certificate Chain) Header
Parameter in section 4.1.6: this parameter indicates where the
token is from.
For an AS/STS to validate an OAuth access token from a different
AS, it is in a similar situation as an RS.
The key point is coming from the following proposed definition: "A
Security Token Service (STS) is a service capable of*validating
and*issuing security tokens".
Up to now, the following definition applies: "A Security Token
Service (STS) is a service capable of issuing security tokens".A
given RS is free to trust (or not to trust)
any AS/STS.
It would need to know the issuer of the access token - this is, I
think, what you've pointed out with suggesting "subject_issuer"
and "actor_issuer".
I believe that I am now starting to understand why you made these
suggestions.
There are maybe different ways that could be conveyed but some
means at least would be needed to indicate the access token issuer.
The "x5c" Header Parameter is such another way. When used, it
should not conflict with any other parameter.
Then the receiving AS/STS would have to call the issuing AS's
token introspectionendpoint (unless it somehow knew how to
validate an access token from that issuer locally). The complexity
of all that is one reason why token exchange scoped validation
(and issuance) of access tokens to only access tokens from the
AS/STS involved in the exchange (and not directly supporting OAuth
access token to OAuth access token cross-domain exchanges). Also
the assertion based authorization grants (RFC7523
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7523&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=12M7sDpIGgB1cZ7S1s3r8RpKeWc5HTrRsC9yfp8a5Fw&e=>&7522
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7522&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=HpMlI_km1n_SSWvj4iPzAwj8Cz44d5EvlJBQ3Q3fA20&e=>)
are largely intended to facilitate acquiring an access token from
an external AS. The thinking (fro me anyway) was that token
exchange would be used with a local STS to obtain an assertion
suitable to be used at an external AS with an assertion grant to
get an access token from that AS. That pattern is something that
exists today. Cross domain could also be achieved with JWTs, for
which a token type value of "urn:ietf:params:oauth:token-type:jwt"
is defined.
It's difficult to articulate but that's an attempt to explain how
things are in the draft today and why.
If we introduce relationships between AS/STSs, we are opening a
pandora box where trust relationships is a concern and where
privacy is also a concern.
Do we want a local AS/STS to be aware of all the RSs accessed by a
client ? Do we want an external AS/STS to be aware of all the RSs
accessed by a client ?
What would mean a "local" AS/STS versus an "external" AS/STS ? It
is from the point of view of the client or of the RS ?
It is normal that an AS/STS issuing access token knows some
attributes related to its clients. Would it be appropriate if
another AS/STS would knowsome attributes from "external" clients
and, in addition, where the access tokens will be used ? We need to
take care of_not building a system_where/by construction/"Big
Brother would be watching you".
The core of problem is well beyond the simple addition of one or
two parameters.
I guess I would have to defer to the larger working group here as
to the question of if token exchange should support exchanges of
an OAuth access token from a different AS for an OAuth access
token issued by the AS/STS doing the exchange?
In order to progress on this topic, I believe that we first need an
architecture paper with a clear description of the trust
relationships and an identification of the privacy issues.
Denis
On Sat, Jul 29, 2017 at 8:46 AM, Bill Burke<bbu...@redhat.com
<mailto:bbu...@redhat.com>>wrote:
So, you're saying the STS has to define a subject_type for
each external token the client wants to exchange from? A type
that is potentially proprietary and different between each and
every STS? On the opposite end, when you want to convert to
an external token, the STS either has 3 options for the client
to specify that it wants an external token. 1) a proprietary
response type, 2) a proprietary resource scheme, 3) a
proprietary audience scheme.
Don't you think at minimum, the token-exchange spec should
define a standard way to do OAuth to OAuth cross-domain
exchanges? Right now cross-domain exchanges are proprietary
and completely up to the target STS on how it wants the client
to formulate a cross-domain exchange. I still think a
"subject_issuer" and "requested_issuer" are the clearest and
simplest way to enable such an interaction.
On 7/28/17 6:28 PM, Brian Campbell wrote:
The urn:ietf:params:oauth:token-type:access_token type is an
"indicator that the token is a typical OAuth access token
issued by the authorization server in question" (see near the
end ofsection 3
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dtoken-2Dexchange-2D09-23section-2D3&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=s8jAnQQQENLsF3nC9--ehae3sweguEX19zTsKsO9o_o&e=>)
so the issuer is the given STS in that case. Cross domain is
possible by use of other token types that are not opaque to
the STS where the issuer can be inferred from the token.
On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke<bbu...@redhat.com
<mailto:bbu...@redhat.com>>wrote:
Thanks for replying,
The Introduction of the spec implies that
inter-security-domain exchange is supported: "
A Security Token Service (STS) is a service capable of validating and
issuing security tokens, which enables clients to obtain appropriate
access credentials for resources in heterogeneous environments or
across security domains.
"
But with the current API if you want to exchange an external token to
an internal one, there is no way for the STS to identify where the
subject_token originated. Are you saying that an STS cannot accept tokens from
an external domain?
i.e
subject_token: <opaque-string>
subject_token_type:
urn:ietf:params:oauth:token-type:access-token
There's just no way for the STS to know where the
subject_token came from because the subject_token can be
completely opaque.
Now, on the flip side, if you are converting from an
internal token to an external one, the audience parameter
is just too undefined. For example, how could you specify
that you want a token for an external client of an
external issuer. Client ids are opaque in OAuth, and
issuer id isn't even something that is defined at all.
In OpenID connect, an issuer id can be any URL.
IMO, adding optional "subject_token_issuer" and
"requested_issuer" parameters only clarifies and
simplifies the cross-domain case. If you don't like
"issuer" maybe "domain" is a better word?
Thanks for replying,
Bill
On 7/28/17 4:39 PM, Brian Campbell wrote:
In general, an instance of an AS/STS can only issue
tokens from itself. The audience/resource parameters
tell the AS/STS where the requested token will be used,
which will influence the audience of the token (and
maybe other aspects). But the issuer of the requested
token will be the AS/STS that issued it. A cross domain
exchange could happen by a client presenting a
subject_token from a different domain/issuer (that the
AS/STS trusts) and receiving a token issued by that
AS/STS suitable for the target domain.
On Fri, Jul 28, 2017 at 9:06 AM, Bill
Burke<bbu...@redhat.com <mailto:bbu...@redhat.com>>wrote:
Should probably have a "subject_issuer" and
"actor_issuer" as well as the "requested_issuer" too.
FYI, I'm actually applying this spec to write a
token exchange service to connect various product
stacks that have different and often proprietary
token formats and architectures.
On 7/26/17 6:44 PM, Bill Burke wrote:
Hi all,
I'm looking at Draft 9 of the token-exchange
spec. How would one build a request to:
* exchange a token issued by a different domain
to a client managed by the authorization server.
* exchange a token issued by the authorization
server (the STS) for a token of a different
issuer and different client. In other words,
for a token targeted to a specific client in a
different authorization server or realm or
domain or whatever you want to call it.
* exchange a token issued by a different issuer
for a token of a different issuer and client.
Is the spec missing something like a
"requested_issuer" identifier? Seems that
audience is too opaque of a parameter for the
authz server to determine how to exchange the token.
Thanks,
Bill
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
/CONFIDENTIALITY NOTICE: This email may contain
confidential and privileged material for the sole use of
the intended recipient(s). Any review, use, distribution
or disclosure by others is strictly prohibited. If you
have received this communication in error, please notify
the sender immediately by e-mail and delete the message
and any file attachments from your computer. Thank you./
/CONFIDENTIALITY NOTICE: This email may contain confidential
and privileged material for the sole use of the intended
recipient(s). Any review, use, distribution or disclosure by
others is strictly prohibited. If you have received this
communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments
from your computer. Thank you./
/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s).
Any review, use, distribution or disclosure by others is strictly
prohibited. If you have received this communication in error,
please notify the sender immediately by e-mail and delete the
message and any file attachments from your computer. Thank you./
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=SSB8VXVhVci3iXTVS-SLtLbF6f2G8iDRsEZtc-yuZpI&s=8Q33IojJDmLmD3eSbPyGO1FcwJBRn5Bz4bSoqJebg78&e=>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
