Re: Current XKRSS test cases

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


Hi Tommy,

I can live with either solution or keep working like now, copying the
shared secrets each time, as long as the number of tests is not huge
(that won't be!).

Cheers,
 - -Guillermo