Issuer vs. STS

Yep, you're right about STS being mentioned in chap 13 of WS-Fed. I think I may have misunderstood Vittorio's comments, but having switched to using Issuer instead of STS I've found that's it's easier for people to understand.

STS is a protocol implementor's term, and I think it could be used in that context. But I still think of an STS as just one piece of the puzzle - it's technically the endpoint you talk to in order to get a token. But it doesn't address the logic, policy, and administration features of an issuer as a whole. So why do we keep referring to issuers (or claims providers, etc.) as STS?

I really do think we should abandon the term STS to protocol wonks.

For someone implementing an issuer, I can see how knowing all the details of the specs, jargon, etc. is helpful. And perhaps I'm arguing a small point, but I'm just hoping to make the barrier to entry for folks building claims-aware apps a little lower by not having them worry so much about protocol details.

That's what WIF is for - to abstract them from that stuff. What's important to me from a pedagogical standpoint is that my audience understands the relationship between the user requesting a token, the issuer of that token, and the app that receives it. The fact that they need to trust the issuer, etc.

And there's a great example. What sounds more natural to you, "Trust your issuer" or "Trust your STS"? Funny how the latter sounds like technical jargon that I can ignore. The former almost feels to me like it puts a human face on the issuer, and gets me thinking about trust between businesses, etc. Cause there's a lot more to this story than just the crypto. The technical stuff is the easy part, right?

A lot of this is gut feel, but I've been talking about Issuer now about as long as I have STS, and I feel tons better using Issuer when giving a talk.

So why don't I use "Claims Provider"? Issuer has less syllables. Seriously. It's less to get your head around. It even has less syllables than STS. And certainly less than Security Token Service. As a side benefit, it directly relates to properties on the resulting security context (Claim.Issuer) in the WIF abstraction layer. Which once again makes me wonder, if the client calls it Claim.Issuer, why does WIF make you derive from SecurityTokenService to supply your issuance policy? It's not very symmetric, is it? And I don't think anyone would buy into renaming Claim.Issuer to Claim.STS...

Note that I'm not in any way disparaging my audience with my "less syllables" argument. I just figure why put up more mental hurdles for a topic that is already a little mind bending to many who are new to this space.