Re: [dss] Pending / TryAgainLater

[Andreas Kuehne <kuehne@klup.de>]

Hi again !

>> > Another possibility is to have a single, separate Async Profile.  This
>> > would make it clear what the approved way of doing asychronous 
>> operation
>> > is, hopefully avoiding the confusion you mention.
>> Do you think of another horizontal profile ?
>
>
> yeah, that's what I was thinking.  (and I see Nick agrees with this).

Hmm,  makes me afraid of the "combinatory explosion" a bit more ...

>
>> Is there demand for several protocol styles  ( XKMS style, home 
>> grown, ... ) ?
>
>
> I'm not sure exactly what you mean by "protocol styles".  But it 
> sounds scary, so I'll venture a tentative "no" :-).

I thought about the different styles of building the async protocol. 
Different naming conventions , e.g. 'Try again' or 'Pending Request'. 
And of course push versus pull : Client polling or being notified using 
a given URL.

>> Anyway, the GermanSig profile badly needs asychronous replies ! In 
>> the worst scenario every signing request has to be commited by the 
>> signature holder explicitly. In the best ( signature law compliant ) 
>> scenario the certificate holders has a time slot ( usually several 
>> hours ) for inspecting the signing request and possible rejecting the 
>> request. So for sure request processing takes hours --> requests have 
>> to be processed asynchronously !
>
>
> It seems to me the best case, and also the most common case, is if the 
> user authenticates himself using the same identity he wants to perform 
> the signature as.  Then he is "committing the signature explicitly", 
> so the signature can be issued immediately.
>
> The asynchronous case would be if the user requests a signature with 
> some identity he hasn't authenticated as, so some out-of-band 
> authentication is required.  That seems an awkward and unusual case.  
> Though of course you know your requirements and laws better, so 
> perhaps I'm wrong.

Sadly the awkward case is my usual case : In my favorite use case the 
invoices ( several thousands )  drop out of a batch job or a message 
queue. These processes usually don't carry any authentication 
information. Especially they don't know anything about the guy plugging 
in his key cards and typing his pin code into the card terminal.

Anyway, if we got the lucky case of the having the card holder sending a 
signing request he may authenticate hisself. But in no case he would 
expose his pin code. So for generating the signature using the key card 
a second step has to performed ! Moreover the signature law explicitly 
postulates the commitment / time slot procedure.

For some time I asked and argued, but now I accept the signature law and 
try to find the best solution for the customers ...

>
>
>> Iirc 'asynchronous request' was on our initial requirement list.
>
>
> You're right.  But at the F2F, we decided to put this aside as a 
> possible v2 feature.

Ohh, I must have been out for eating a donut ;-)

>>  Blame it on me that I didn't track this requirement and now come up 
>> with a 'must have'  ...
>>
>> > But by keeping it out of the core, we would keep the core smaller and
>> > easier to implement in its entirety.
>> Sure ! But on the other hand 'asynchronous requests' seem to be a 
>> generic mechanism valid to be part of the core !
>
>
> Yup.  It is generic, and it would be reasonable to put it in the 
> core.  I just don't think it's the best idea, cause I think the demand 
> for this amongst concrete profiles is small (only code-signing so 
> far), and it's a significant change to the processing model, so it 
> adds a lot of complexity.

Yes, agreed. Especially if there will be different asynchronous profiles 
for push and pull its a good approach to separate this aspect into profiles.


Greetings

Andreas