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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
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./
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
