Client secret in SAMP recommendation

[Mark Taylor]

On Tue, 3 Feb 2009, Juan de Dios Santander Vela wrote:

> Hi, I've been using a direct XML-RPC client against both JSAMP-based and 
> SAMPy-based hubs, and I've found that the method signatures in the SAMP 
> Proposed Recommendation do not show the client private-key.
>
> Don't you think they should be added?
>
> I understand this is covered in section 4.2 items 2 and 3, but I think it is 
> much more informative if it is present in the method signatures themselves. 
> In the way they are written, they resemble more ancillary code one would 
> write in a class, which would then take care of doing the appropriate call. 
> In the way I propose they would more closely resemble the actual XML-RPC 
> call.
>
> This is a minor issue, as it is covered in the manuscript, but I think it 
> could be taken into account after approval by the IVOA Exec.
>
> ps. Before sending this e-mail I've seen that Luigi run into a small problem 
> with SAMPy implementation just because it was not clear what was the first 
> parameter to be sent in those calls, so I guess it is not such a bad idea ;-)

Hi Juan,

I sympathise with your experience, and I agree that for users of
the Standard (XML-RPC) Profile, it's less obvious what to do given
that the private-key arguments are omitted as the document stands.

However the thinking behind writing the standard like this was to restrict
the abstract API to the basics which any profile would use.  One can 
imagine a profile based on a transport protocol which provided client 
identification automatically, and in this case the private-key arguments
would not be necessary, so would not appear in the profile-specific API.
Looking at it this way, it makes sense for such 'profile-specific details'
to be omitted from the abstract API.

Earlier drafts of the document had the private-key arguments in place
as you suggest, but they were removed following arguments by 
Mike Fitzpatrick and Doug Tody along the lines above.  Although I 
wasn't sure at the time that this was an improvement, I'm inclined 
to feel that at this stage in the progress of the document it's 
better to leave it as it stands.  If you want to press the point,
by all means follow up this response; in this case perhaps Mike or 
Doug could make the opposite argument (the original discussion 
is not archived on the list since it was in private authors + Doug 
emails).

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/