[foaf-protocols] Fwd: [WRAP] RFC formatted versions of OAuth WRAP

[Peter Williams]

Folks have the notion of a transport session, distinct from a web session.
SSL is one such session technology for transport sessions (between
"desktops", not client/servers), and TCP sequence numbers are another
(between hosts, vs IP routers). TCP's halfclose semantics are carefully
integrated with SSL's half close and role switching, so one get
bidirectional (crypto) session "persistence" even when the TCP channel is
rebuilt.. In the higher-layer ws-security world, derived-tokens formed FROM
an initial ws-trust handshake form the "ws-secureconversation context" -
providing ongoing "session persistence."

 

When doing Req/Resp design flows over named pipes or shared memory
transports, one needs those feature-poor transports to be able to support
the usual semantics required for distributed objects - arrive only once,
allow tightly coupled data services to participate in 2 phase commit for
transaction backout. and all the other things we all got schooled in
concerning enterprise "distributed systems" middleware - in the early 80s.
Such as WRAP add those 80s "research" features to the 2010 plebian web. (Why
they don't add DTLS with mac-based ciphersuites to named pipes instead..I
don't know!)

 

If you're a windowstype, you can see all this playing out in Microsoft's RIA
security middleware for offline ajax clients and Silverlight clients. There,
json-based services enables an app running in the browser to access identity
verifier and role checker services operating AT a server, whose response
tokens are issued to the "trusted" client app -  which guards access to
client-side data and state. The tokens have to work in their "security
enforcing function" even when the client is operating in offline mode (as
when invoking Microsoft word for web when disconnected from the internet,
especially if its implementing its DRM or "rights management" functions.)

 

So don't get me wrong. There is lots of good and cool stuff going on. One
just has to monitor the control impulses of certain societies, that always
want to sell you more and more "protection" services - whether you need them
or not.

 

 

One question I posed on the OAuth mailing list was why there is a need for
an Access Token, once an identity has been verified.  (This sort of reminds
me of a login cookie once you login to a website).  

I got the response: 'I know what you're getting at, but see session fixation
and a few other security issues as to why a new token is issued once the
request token is verified.'

I guess this means in the FOAF+SSL world we need to be wary of browser
sessions being hijacked, and that an Access Token is one way to protect?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100116/e3d42a3c/attachment.htm