<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>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).<BR> <BR>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.<BR> <BR>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<BR> <BR>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).<BR> <BR>Ok. I get it.<BR> <BR>Federation metadata automation, and control projection - layered on top of private(*) trust graph formation.<BR> <BR>(*) private as in not-public. "community of interest", in other words.<BR> <BR> <BR> <BR> </div></body>
</html>