[OpenID] assurance concepts for OAUTH

[Peter Williams]

I'm taking a good long hard look at OAUTH, these days, mostly because Microsoft have integrated it (much like signed DUA and signed DSA chaining operations from CCITT's X.500 1988 work) into both their Azure Directory tenant services and their data service API frameworks, more generally. This tells me there is a certain maturity - a signal that I'd be prudent to note. One thing I note as I read is an omnipresent assumption - that is really just not warranted. Much of the terminology and the design features implied by wording would have it that oauth tokens are directly consumed by resources, with application-layer access control guards. From everything Ive learned over the last 5 years of token-passing schemes deployment, it is rare - outside webby/scripting php/asp.net type software - that legacy resource systems for lines-of business type software directly consume the tokens. Rather, they have their proprietary/legacy guards and expect to continue to use them - now supported by a translation unit converts such as oauth tokens into the proprietary/legacy token. For example, a SID claim in an oauth token may well be what drives the ACL function of a windows-centric guard, when accessing a file resource. A trusted process (in assurance theory) converts the oauth token to the SID, and the SID and the ACL rules are enforced by the reference monitor all of whose integrities are secured by the kernel of a CC-evaluated OS. Typically, the process must also translation authorization constructs, from layer-7 group constructs to properly-designed resource-centric groups maintained by such as a AD GC server. For all I know, this may all be driven by an OAUTH/Kerberos-ticket handoff. Folks may want to bear in mind the assured world, when writing. Not everything is a php script working with name/value pairs.     		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20121024/4ccdb484/attachment.html>