Re: spec: 2 changes, UML sequence and protocol

On 6 Mar 2011, at 23:24, Stéphane Corlosquet wrote:

> Hi Henry,
> 
> On Wed, Feb 23, 2011 at 1:08 PM, Henry Story <henry.story@bblfish.net> wrote:
> I have made the following 2. changes to my local git repository that are slightly related
> 
> 1. UML sequence
>  - Added a UML sequence diagram in graffle and jpg format (so others can edit)
>  - Added that UML into the spec
>  - also added the graffle source for the other image
> 
> 2. the protocol sequence
> 
> I then had to look how the protocol sequence fitted the sequence diagram, which led me in a second step to:
> 
>  - remove the implication that the authentication server must authenticate ALL the WebIDS. Peter Williams had some very convincing arguments as to why that was a bad idea
> 
> from your modified version of the spec: "If the public key in the Identification Certificate is found in the list of public keys associated with the claimed WebID URI, the Verification Agent can place it in a list of verified WebIDs."

> This sentence does not make sense: "place it", you mean place what? the public key? no, here you mean to place the WebIDs dereferencing to a document containing the public key into a list of verified WebIDs.

yes. Is this better?

If the public key in the Identification Certificate is found in the list of public keys associated with the claimed WebID URI, the Verification Agent can place that claimed WebID in a list of verified WebIDs.


(I think we need to go over the text with someone who is good at english grammer of indexicals, and remove the unecessary duplication of names that appear all over the place and make the text heavy to read.)

> But then, you are not addressing Peter's concern by removing a good chunk of text from the spec: how do you build this list of verified WebIDs?

That's detailed in step 3

> does it have to be an exhaustive list?

of claimed WebIds? In my view no, but I am ok with leaving it like that now, and having another issue to decide that. 

> after how many failed or verified WebIDs do you stop?

Up to the implementation. We don't need to specify this. See point 4. It must do 1, but can do more.

> That's something WebID authn implementers will need to know.

Yes. That is in the current text.

> 
>  
>  - reordered the sequence of events: TLS private key authentication happens before the certs are extracted before other layers get access to the certificate.
> 
> why in this order? I would think that the order does not matter, as long as both the TLS authentication and the public key verification of the WebID profile document are both done before authenticating a user.

Because I think in all current implementations of TLS the private key verification of the client certificate is done before anything else. In most implementations the code receives the certificate where that has already been tested... If you put this part last in the sequence, implementors will wonder how once they have the certificate they go around proving the private key of the client matches the public key. That is dealt with at the SSL layer.

> Why can't they even be done in parallel to speed up the authentication process? (e.g. fire up the WebID document retrieval while performing the regular TLS authentication).

They could be done in parallel. 

But how do you propose we cover this in such a way that this optimisation can be programmed by advanced TLS experts without making the steps unintuitive to programmers who don't ever delve down
to that level?

Perhaps we need to cut the main steps into the three core parts:

 1. open connection by client
 2. server
           a+ proves client controls public key
           b+ proves public key identifies the client

 And we specify that both of those can occur in parallel. The authorization step can also occur in parallel btw. So for example the server could use the authorization engine to decide which WebIDs have any chance of being acceptable for authorization. But at the end the pieces need to be tied together.

> 
> you're also adding this step #6 in the authentication sequence:
> "If one of the verified WebIDs is authorized to access the resource requested, the Verification Server should serve that resource. "
> 
> Strictly speaking, this is authorization, and out of the scope for the authentication steps. Removing this step would also cut in half the complexity of the UML diagram, which looks quite complex as it is. Your diagram contains the full picture authentication + authorization, which would fit better in the examples / use cases.

I agree that it is not strict. But if the sequence diagram at the top is to make sense the authorization step has to be shown: A sequence diagram where 7 is not show would be an incomplete protocol.

So perhaps what I can do is grey out somehow step  6, and mention it as a place holder for an authorization sequence?

6. The Verification Agent uses the list of verified WebIDs as input to an authorization step.
7. Depending on the results of authorization in step 6. the Verification Agent can serve or refuse to serve the resource requested in step 1.
 


> 
> Steph.
>  
>  - removed the note about  "a digital signature challenge" that was never discussed
> 
> My version is here:
>   http://bblfish.net/tmp/2011/02/23/index-respec.html
> 
> If you press cntr-alt-shift-S in your browser you will have a dialog that will allow you to get a visual diff from the current version. It seems to have a bug as it shows a lot more changes that were made.
> The only relevant ones are in section 3.1
> 
> I am trying to find a tool to give me a url for a visual diff of the source code between the two versions but was not able to find one.
> 
>  Feeback welcome,
> 
>  Henry
> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 
> 

Social Web Architect
http://bblfish.net/