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