use of JWT and / or STS with Shibboleth IDP?

[Klingenstein, Nate]

> I think you mean 6750, but yes, if you don't need a standard token format, then, well, you don't.  That's most non-OIDC uses of OAuth.

Yes, I did, sorry.  Whoever edits RFC's needs to smack me upside the head with a +1.

> Obviously all those are features to the people who created JWT, and JWT is the standard JSON format security token.

No argument here.  Personally, I don't think they're features.  The distinctions are lost on me, but more importantly, I can't explain any of this to the people who are asking about this.

> But I agree very much that the dominant usage is opaque tokens and callbacks, and a lot of that spec work is going to go to waste.

That's a great statement of what I've been fumbling with.  Let me tee it up in case anyone has more.


If you're just going to do a query over HTTP GET over TLS for an opaque token, just do a query over HTTP GET over TLS for an opaque token.

If you don't care about the content, then you don't care about the content.  Put as many wrappers around it as you want; it's opaque to you.

If you care about the content, then you better care about the content.  You can't care about part of the token(uniqname:token) and not the rest.

If all you want is "IS IT YES?"  "YES"/"NO", that's the most degenerative case of not caring about the contents.  200 is yes, anything else is no.  Shim, proxy, direct, whatever.

If you want a real STS or PDP or something, then you're writing a policy language and building something novel and real and I want a specification for it.