[foaf-protocols] new sequence diagram

[Sebastian Tramp]

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.

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 at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols


-- 
WebID: http://sebastian.tramp.name