RE: OAUTH setup for webid : getting an ODS client to "Connect" to my profilepage

The almost anal focus on the browser as the only web platform hurts webid. Its another one of the those cultish matters. The concept that only a website delivers keying is also not helpful, or that key stores are in some sense provisioned to or via browsers talking to "IDP sites", is not helpful. Webid tends to look absolute and unyeilding (and typical, old-school W3C). In our world, folks have desktops. It appears to have icons, including a browser icon and a membership-system icon. When the click on the icon, they are actually starting up an rdp session to a particular host, which runs the remote-UA in a local window (X windows like). They cannot tell the difference between this and an app executing on the PC (largely). Kerberos does magic to manage the illusion over the VPN, typically. the non-browser app delivers a UI experience that browers do not (with milli-second screen refreshing and interactivity). And yes, we tried embedded activeX and java controls to get that....and failed to get user buyin. The point is that they - the users- expect the local browser-UA ( running in their hotel room in Japan) and the app-UA (back in the office server room, in Washington DC) to behave the same, re their keying. What happens in a directory-managed environment is that the remote App process is also logged on as the user, with a local directory session. In key management terms, the user has just roamed to a new PC, and expects their full desktop experience (including keys) to roam with them. In fact they are on 2 PCs at once (they just dont know it). They may be on 3 PCs at once (and have 0+2 roaming sessions) if they open multiple membership UAs windows. The terminal server hosting this remote-UA may be several machines, and be located at a data center closest to the actual user (for lowest latency). (This is how Fortune-100 folks do it, using directory site replication). The key roams, courtesy of normal activeDirectory-based certificate store. Only in the special case that the user is using a smartcard reader for keys/certs does this directory-based roaming go away, and everything all ties back to a particular PC (hosting the card reader in the USB slot). This requires quite advanced middleware in both the PC and the card (its not just the dumb end PKI cards, from 1996, when we all last tried giving the public a million client certs). It requires multiiple channels to be managed, using better-grade PCMCIA channel IO handling and then layer 7 signalling (which has its own security protocol for the PDUs shared between card and remote data centesr(s), courtesy of IBM Zurich). So, at some point, webid needs to get enterprise-centric - and thus speak to that community in terms it understands. I need your RDFa page of descibed service to also be delivering such an illusion. As it can be literally downloading the SSL client protocol engine and the root key store to the browser, it can also be delivering the users client-cert keying - FOR THAT browser page, via reference to an entity that delivers the keying mateiral (while also describing said entity). The spec is correct in some sense to be distinguishing between the key agent and the browser - though I susepct Henry was just thinking about his little Apple key chain UI metaphor. But, at least the concept was established that the browser is not the repository of keying. Its using a crypto service, that is keyed; just like other web-applications on the (rather illusory) desktop, and just like web applications that are wholly self-contained within a DOM instance, as with javascript-based https clients.                 Date: Wed, 11 Jan 2012 08:55:16 -0500
From: kidehen@openlinksw.com
To: public-xg-webid@w3.org
Subject: Re: OAUTH setup for webid : getting an ODS client to "Connect" to      my  profilepage


  


    
  
  
    On 1/11/12 3:11 AM, Peter Williams wrote:
    
      
      
        I deployed a authorization guard at my idweb site. if an OAUTH
        token is sent to the webid endpoint, its evaluated using webid
        validation logic, assuming it contains a cert in the OAUTH
        claims. If I gave out the key, I dont see why an OAUTH v1 token
        could not  be formualted directly, rather than doing what is now
        described.

         

        The scenario fits one of our products, that is a thick client
        (using web services, including rest-based web services). How
        would I make it apply the webid world (since its not a browser)?

      
    
    

    You should be able to simulate a non browser UA using cURL re.
    RESTful interaction patterns. Then we get into pem, .p12, and local
    keystore API bindings on the client side re. WebID. 

    

    
       

        The UA has the users signing key, shared with the browser
        - since they are on the same windows machine typically. All apps
        on windows share keys (given security rules). A demo UA signs a
        SAML2 token targetting the my webid profile resource which the
        resource STS in the cloud converts into an OAUTH v1 token
        (signed using an hmac known between it and the profile's
        guard). This is returned to the UA, which installs the OAUTH
        token into the www-auth header accompanying the web request,
        which thereby forward the name and the cert (as signed by the
        cloud). This only happens if the cloud has verified the
        certificate and SAML assertion's signature classically (with no
        webid rules) The guard receiving the www-auth header then
        evaluates the additional webid rules (with no PKI rules), since
        it has a cert (much like SSL delivers a cert). Failed or happy
        verification returns an exception (403 or 200).

      
    
    

    Yes. 

    

    This is just more inter-protocol plumbing. 

    
       

        Anyways got some kind of validator up in the cloud, using the
        cloud STS to do the heavy validation, leaving to the webid
        validator handling of the one particular extension (and
        modulus/exp) webid cares about. This allows the edge devices
        (i.e. the cloud STS) to be shielding mere resource servers from
        DOS - and enforcing proper cert handling, cert chain discovery
        etc.

         

        Not going anywhere, but its fun to see how webid will surely
        evolve - and work with all the othe security technology
        families. Seems to have a nice fit, once divorced from SSL.

         

        Ok. tomorrow, can try again at SSL. Lets finally see what Azure
        does with client certs, since there is load balancer in the way.

      
    
    

    Okay. 

    

    

    -- 

Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen