OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] Pending / TryAgainLater


At 10:40 AM 4/7/2004 +0200, Andreas Kuehne wrote:
>Hi Trevor !
>
> > 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).


>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" :-).


>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.


>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.


>  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.

Trevor 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]