Re: [OAUTH-WG] OAuth WRAP

["RL 'Bob' Morgan" <[e-mail]>]

Finally looking at OAuth-WRAP draft, it occurs to me that there is some 
context to the architecture presented there that might help.  Let me say 
that I haven't been involved in the development of WRAP, so might be 
getting this wrong from the point of view of WRAP folks, I apologize if 
so.

The concept of a "security token service" (STS) has been developed and 
promoted as an architecture (or pattern, perhaps) in the community that 
might be variously labelled as WS-Security or WS-* or SOAP-based Web 
Services.  Searching for the phrase will reveal lots of explanatory 
material.  At least in enterprise circles the STS concept has become 
pretty well accepted, even if not so widely deployed.  As a concrete 
WS-based service the STS is accessed via the WS-Trust protocol.  WS-Trust 
conveys security tokens but is intended to be token-neutral, that is, it 
can be profiled to carry many/most/all tokens associated with existing 
security protocols.  A WS-Trust-based STS then (in theory) can translate 
between what a client has and what a resource server needs.  This pattern 
is appealing in large organizations to centralize token issuance in the 
face of many apps with heterogenous security protocol needs.

It is my impression that the discussions that led to WRAP were around the 
observation by some large organizations that they find the STS pattern 
attractive to manage access with partners of all kinds; but that the WS-* 
stack is hard to deploy; and OAuth does something much similar and is much 
easier to deploy.  So they'd like a "RESTized STS" or a "OAuth with an STS 
in it".  That's more or less what I see in this proposal, though I haven't 
read it in detail.

So, eg, statements about "opaque tokens" in WRAP as far as I can tell 
aren't meant to distinguish it from OAuth 1.0 but to reflect the design 
inputs from WS-Trust and STS.

  - RL "Bob"