Android Application Question

[Cantor, Scott]

On 1/4/17, 3:22 PM, "users on behalf of Klingenstein, Nate" <users-bounces at shibboleth.net on behalf of nklingenstein at calstate.edu> wrote:

> I'm convinced that applications are never going to relinquish enough
>    control to an external module for them to ever grasp that they can
>    conceivably be different.  This is why I didn't think deployment
>    profiles versus implementation profiles necessarily exist, and I know
>    you disagree with that stance, as well.

We aren't solely splitting them because of the SP, that's much more about IdPs.

But to be blunt: if you're correct (and I am not claiming you're wrong), then all the things you're proposing are equally time wasted. They will do nothing. Not my approach, not OIDC, not yours. Nothing. That's just what they do. You can't make it simple enough.

>  CAS has a variety of things that can come back.

It didn't though, not in the beginning. Why did it change? Because people wanted more. So think about that.
 
>    simpleSSO rips out all of that and relies on HTTP and TLS for everything
>    on the premise that it's much easier for applications to use right and
>    somewhat harder for them to use it wrong.

I'll beg to differ, but you know that.

> Well, I would call SAML assertions in the front channel a pretty
>  spectacular widespread deployment success.

One big exception doesn't invalidate my point.

Plenty of people implement SAML or OIDC  (and CAS) exactly like you're suggesting, by just doing blind TLS callbacks. I suspect most do. You don't need a new thing to dumb the world down to that, just tell people they should ignore all the standards and security considerations language MUSTs, and just make a callback. If they balk at that because it sounds wrong, well, I think people need to own their decisions and not hide from them.

But i think you really just want OIDC, which is fine. If the specs are throwing you, keep in mind that nobody writing the libraries is probably reading them.

-- Scott