Re: Current XKRSS test cases

Hi Tommy and Guillermo,

I think we should do ourselves a favor and make the tests repeatable without
having to re-register user again in order to get new secrets. So I prefer
fixed secrets.

Thanks !

Yunhao


> I am also in favour of not stating the shared secrets for authentication.

How you distribute the shared secret is out of scope in XKMS so we
need to be agile in this matter.  In my case, I have web ui that
allows for a single click generation of shared secrets for all
purposes.  However, I recognise that some people are concerned about
automation and I am therefore prepared to use a hardcoded shared
secret (e.g. "secret") *as long as* we assign a name to that key, for
use in e.g. a KeyBindingAuthentication.Signature.KeyInfo.KeyName
element.

The ideal thing would be to use a shared secret exctly once - this is
after all the specifications intention.  Consequently,  implementors
may have taken design decisions to prevent multiple usages of a single
shared secret. In the light of this, I have prototyped a "service"
through which a client can programmatically obtain a set of shared
secrets.  It consists of some minimal request/result markup.  This too
is out of XKMS scope, but can be implemented with minimal effort.

How do people feel about the two options?

Regards
Tommy

On Thu, 25 Nov 2004 13:54:52 +0000, Guillermo Álvaro Rey
<alvarorg@cs.tcd.ie> wrote:
>  El jue, 25-11-2004 a las 13:03, Tommy Lindberg escribió:
>
>
>  In test cases XKRSS-T1 to XKRSS-T5 what is purpose of the value KeyName
> column? Regards Tommy I think we should get rid of it. In fact, when
writing
> the sample messages we wouldn't need the table at all. Besides, it would
be
> consistent with XKISS tests.
>
>  I am also in favour of not stating the shared secrets for authentication.
> As a matter of fact, when testing against your server, I am using the
shared
> secrets found in your enrollment site and not the "secret" string.
>
>  Cheers,
>  - -Guillermo
>
>
>

Received on Sunday, 28 November 2004 15:43:06 UTC