On Tue, Aug 1, 2017 at 4: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 in
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-2.1>
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://tools.ietf.org/html/rfc7662> 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 (RFC
7523 <https://tools.ietf.org/html/rfc7523> & 7522
<https://tools.ietf.org/html/rfc7522>) 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 know some 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 of section 3
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09#section-3>)
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://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
/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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<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://www.ietf.org/mailman/listinfo/oauth>
/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./
