Finally, here are the additional notes I took on the OAuth/WS-Trust session Ashish Jain moderated at the recent(ish) SSO Summit, to supplement his post.
In addition to the use cases already mentioned by Ashish, we discussed use cases for having a security token service in its most basic form. There are “syntactic” reasons to need to exchange tokens:
- Going from a proprietary token format to a standard one (e.g., Kerberos to SAML)
- Going from one standard token format to another (e.g., SAML1.1 to SAML2)
- Going from one proprietary token format to another
The participants considered this pretty much a “necessary evil” for integration purposes — a tactical need that is likely to subside over time as standard token formats stabilize, converge, etc. We saw both internal and cross-domain uses for this, but identified today’s WS-Trust sweet spot as being within enterprises where multiple token formats are (still) in use.
Then there are semantic reasons to exchange tokens. For example, “identity oracle” use cases might have a need for this (handing out a cooked/computed assertion that someone’s “over 25” rather than sharing their actual date of birth).
There are as many unique use cases here as one can imagine. I noted that Liberty ID-WSF has a few of these baked into services that it has defined, but they don’t currently use WS-Trust. (As an aside, there’s a group taking the first steps in a rapprochement here, appropriately pronounced “sig-wish“! Check it out, and let me know if you’re interested in helping.)
