Re: The other side of WebID / four party auth

It's structurally similar to what I proposed in my abortive Phd dissertation (zehr krap). For 2 peers, use acl rewriting in 3 phase handshake (3 per side) to write public data to 2 guarded records.

I wrote cross certs (resigned other parties public key) to an acl controlled directory entry. But the structure is the same.

My thesis was that the world that did this kinda thing was that which would adopt digital signatures, which didn't go down well with military- and gchq- indoctrinated examiners (who felt threatened) by that condition.

It was my own fault, since I picked um!

On Jan 26, 2011, at 6:17 PM, Nathan <nathan@webr3.org> wrote:

> From a mail a moment ago to Peter on foaf-protocols:
> 
> [[[
> Essentially, the protocol is a case of:
> 
> this is my key pair (present certificate, let TLS confirm it's valid)
> this is my webid
> protocol = deference webid, check if "owned" key is found, if so assert that user has authority over the resource identified by the webid-minus-frag, and thus webid is a valid name for them
> 
> ..snip..
> 
> However, I'm positively more interested in getting a list of ways in which the dereferencing process can be abused / hacked / man in the middled, as that's the biggest grey area in all of this at the minute.
> 
> On that note, we should really be giving ourselves https:// scheme webids to prevent the man in the middles, and force TLS across the wire there too, which would give far more scope for the protocol to become an OAuth replacement, since one could repeat the flow with our storage agents to only allow trusted servers access to our information, and to log + identify everybody accessing it, but that's a different topic.
> ]]]
> 
> This is the four party auth I mentioned earlier in the year, but never mentioned in detail, roughly the protocol would be:
> 
> client: this is my cert (key pair w/ webid) - CC
> server: this is my cert (key pair w/ webid) - CS
> client: take webid from CS, place in CC-webid foaf file
> server: take webid from CC, place in CS-webid foaf file
> client: check CS-webid foaf file for CC-webid and CS-key
> server: check CC-webid foaf file for CS-webid and CC-key
> 
> The above covers all bases, it ensures the user and the server are who they say they are, still have write permission to their respective webid resources, ensures HTTP+TLS in all communications, allows ACL controlled responses from each webid resource to only give the (server or client) access to the info it's allowed to see. And it would be webid for the server too, and get rid of the traditional trust chain, making room for new linked-data web of trust.
> 
> Essentially, this would replace everything from openid to oauth and beyond.
> 
> thoughts? and apologies it took me so long to mention properly on list.
> 
> Best,
> 
> Nathan
> 
>

Received on Thursday, 27 January 2011 04:54:44 UTC