Re: [foaf-protocols] new sequence diagram

On 20 Nov 2011, at 17:19, Sebastian Tramp wrote:

> On Sun, Nov 20, 2011 at 03:35:06PM +0100, Henry Story wrote:
> 
> Hi Henry,
> 
> one thing which pops up when I look onto it is: Does anybody know what
> this cloud means?
> 
> so my suggestion is to add a "FOAF Graph", "Friends Network" or whatever label
> on it to make it more clear.

Well the cloud is information trusted by the server taken from the web and which it uses
to make trust decisions. We speak of foaf in the spec at present but it is not meant to be mandatory,
as companies may prefer other vocabularies to describe business relations, etc... 

But yes, we should make that clear in the text.

> 
> Best regards
> 
> Sebastian Tramp
> 
>> In discussion with Bergi, he convinced me that the diagram as it was shown did not make clear enough which 
>> parts were optional, and what was the core of the WebID authentication. So I drew the diagram up again making
>> the authorisation optional, and highlighting the core of the WebID authentication with a yellow background.
>> 
>> 
>> 
>> On 20 Nov 2011, at 14:04, Henry Story wrote:
>> 
>>> Peter Williams had some criticism about the sequence diagram, which it is true whilst being simple is perhaps merging too many things together.
>>> 
>>> So I propose the following much more precise diagram. I plan to also create a state diagram that would show interactions 
>>> more clearly. Here we are looking at a request that succeeds.
>>> 
>>> 1. We set up a TLS session. The server authenticates.
>>> 2. The application layer protocol starts. It passes a guard which can look at the application layer protocol metadata
>>>   and request the client certificate if needed. (the guard can have access to ACL information to make this decision)
>>> 3. the Guard decides 
>>>    a. client authentication is needed  (it's not available in cache) and asks the TLS layer to do that
>>>    b. the TLS layer sends a client authentication request
>>>    c. the client selects a certificate
>>>    d. the TLS agent verifies only that the public sent in the certificate can decrypt the encoded token
>>>       ( we need to find the technical jargon for this)
>>>    e. if it does the guard ends up with the client certificate
>>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>> 4 . The Guard needs to verify the WebID claims in the certificate, so it sends those to the WebID verifier that follows the
>>>   well known procedure, either going through a cache or fetching directly the information on the web (5)
>>> 
>>> 6. given the identities the guard can decide whether the user with that identity has access to the resource requested by considering
>>> its ACLs and the graph of trusted information. (out of scope of detailed study here)
>>> 
>>> 7. the resource is given access to and the server can send the application layer response to the client
>>> 
>>> -----
>>> 
>>> The good thing in this diagram is that
>>> 
>>> 1. we can make clear that the TLS agent can be bog standard - it just needs to not throw an exception if it does not recognise the issuer.
>>> 2. The guard is working at the application layer, and can communicate with the underlying TLS layer.
>>> 3. we don't need to specify what the protocol of the request is - but we can give examples of HTTP requests
>>> 4. the above makes clear how we can get around any browser issues, and how we can get rid of the most problematic user interface problems: namely the automatic request of the client certificate
>>> 
>>> Henry
>>> 
>>> 
>>> 
>>> Social Web Architect
>>> http://bblfish.net/
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> 
> -- 
> WebID: http://sebastian.tramp.name

Social Web Architect
http://bblfish.net/

Received on Sunday, 20 November 2011 16:32:27 UTC