ISSUE#1: SERVERGUIDANCE? (SIGN REQUEST DISCUSSION)

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Dear all,

After the closure of yesterday's conference call Nick, Ed, Trevor and myself
continued talking to detail how to proceed in order to set up the discussions
that eventually would lead to an agreement on the XML schema for the
signing request message. As you will remember it was agreed that the 
discussions would take place through messages sent to the list, so that
all the members of the TC could give their feedback.

It was agreed to launch one discussion thread for EACH identified issue, just
to avoid extremelly large messages with lots of issues discussed inside. It
was
also agreed that I would launch the discussions and send the first group of
messages,
so this one is the first of a number of messages that I plan to send today,
each one
identifying one discussion issue.



ISSUE#1. ServerGuidance in Trevor's proposal.

Short description: This is a root child element in your proposal.
It contains the following children:
	ClaimedIdentity, giving details on the requester claimed identity
	IntendedAudience, a list of recipients of the signature 
	ApplicationProfile, identifying the application profile
	Other: open element that can contain whatever one wants....

Short rationale: you say that:

	1."These all represent general information given by the client to the
server, to help 
	the server decide processing details." and

	1. "these are things that don't correspond 1-to-1 to any particular element 
	of the signature.  The server can take these things into advisement in 
	determining what key to use, what signed attributes to add, etc.."



My proposal distributed these informations in different places:
	1. ClaimedIdentity as an isolated root child.
	2. IntendedAudience and ApplicationProfile as children of element
ProcessingOptions,
	which in turn was one of the children of Options element, which was a root
child.

Rationale: I contend that
	
	1. ClaimedIdentity is an information completely different from semantic
point of view
	with respect to IntendedAudience and ApplicationProfile. It deals with
something
	of extraordinary importance: WHO wants the document being signed!, on behalf
	of whom the server will sign the document(s)!!!, and this for me is a
strong reason
	for not grouping it in the same element as the other three within an
element called ServerGuidance.
	
	2. IntendedAudience and ApplicationProfile are strongly related with
processing options from
	the server perspective. The first one instructs the server to send the
signature to a list
	of potential recipients. The second one contains an identifier of a
profile that instructs how
	the signature will have to be built.

	3. Although these three informations are the only ones that do not correspond
	1 to 1 to contents of the Signature element, I still think that the
semantic implications
	of each piece of information is a stronger reason to keep them separate
and distributed as
	proposed.


In the next messages I will identify more additional issues.

Regards

Juan Carlos.