[OpenID] openid connect as metadata management (windows)
Peter Williams
home_pw at msn.com
Fri Oct 18 20:49:45 UTC 2013
I have to admit I deliberately avoided the oauth movement - when it was about stuffing a third-parties frame into a facebook or google controlled page. This was far too webby (and likely to be transitory).
I have to admit I deliberately avoided the oauth movement - when it was about putting apps on devices, controlled by app stores. This was far too much about app stores and flogging dollar apps to teenagers.
I have to admit I deliberately avoided the oauth movement - when it was about having native app code get tokens to consume API, limited to a given users' entity scope. This was interesting, but too immature - since oauth control processes used by vendor A's API didn't work with vendor B's API. Far too much like the IM wars between yahoo, AOL, Google, etc
I totally get - however - the "novelty" of Microsoft's application of oauth2 (and "openid connect"?) for automating the process of adding an RP site to an IDPs relying party list (known as adding an "SP-connection" in pingfederate land, or a "relying-party trust" in Windows ADFS land). This seems to be a leap forward, in the TRADITIONAL world of websso. It automates some of the tedious federation-metadata processes, typically done offline by admins. And it does so in a manner that is ALSO about device control - giving the "controlling IDP" some power over the devices ultimately used by user of the RP app/webapp, ... logically to remotely wipe them...whenever the IDP want (or some govt issues a secret order).
Ok. I get it.
Federation metadata automation, and control projection - layered on top of private(*) trust graph formation.
(*) private as in not-public. "community of interest", in other words.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20131018/5bc916d9/attachment.html>
More information about the general
mailing list