Registration issues

All,

	I am currently working on the Registration Issues. The following
problems have been identified:

1) Requirement for a key agreement to provide perfect forward secrecy in
the delivery of the private key

2) Need for means of sending additional data such as a credit card
number with the registration request.


Discussion:

The Key Agreement requires:

1) A means for sending client key agreement parameters with the request
2) A means for receiving the service key agreement parameters with the
response

The Credit Card Registration problem requires some way to add
attribute/value pairs into the request.


The problem that we end up with here is that XML does not actually
extend quite the way you would want it to. In particular you can't
extend AbstractRequestType and then have the extension inherited by the
RegisterRequest. The inheritance scheme is static rather than dynamic
(kinda makes you wonder why given all the mechanism they have
arround...)

We have ClientOpaque data in the schema already, but that has a very
specific use. 

On possibility is that we simply consider this a form of
NotBoundAuthentication data. This seems somewhat niche.


One way round this problem would be to simply add in a tag/value pairs
list into the request... I dislike this since it is not really the XML
way, we are introducing private syntaxes.

The question that I am asking myself is, OK we add in a slot for the
credit card info, will that only have utility if the client and service
understand the semantics? So does an extension schema seem reasonable?
Perhaps even desirable if the schema can later be picked up by a
payments working group.


The problem with the extension schema is that I have to extend the
request instances. This does not seem right, I am doing XKMS with
curlicues and the firewalls should know that is what is going on.


So what I propose is that we extend the message abstract type with a
single abstract extension element:

<AbstractExtensionElement>


So extension schemas can extend that type and declare a substitution
group into the message.

In effect this returns us to the <Any> functionality we started with but
we can do the extensions in a completely principaled way.

		Phill