Re: xkms:AuthenticationType Schema Definition Issue

Hi Matt,

The authenticated identity could also be established via the
transport protocol (e.g. https+digest-auth), so its ok to
allow both of these to be missing.

Similarly, its ok to have both present - multi-factor
authentication being a well-known way to decrease the probablilty
of error.

So the intent in this case was not to define a "choice".

(BTW: what's the default for maxOccurs? e.g. does the current
schema allow >1 instance of a NotBoundAuthentication? I think
its ok either way, but the question occurs to me now that I
look there again.)

I guess that one could define other schema structures to
handle this which'd be more precise, but I doubt that that'd
be worthwhile on its own.

Cheers,
Stephen.

Matt Long wrote:

> All, The complex type AuthenticationType defines two child elements in 
> *sequence* both of which have minOccurs="0", i.e., 
> KeyBindingAuthentication and NotBoundAuthentication. Based on the schema 
> definition alone it would be possible to send a RegisterRequest, 
> ReissueRequest, RecoverRequest, and RevokeRequest with an Authentication 
> element with neither a [KeyBindingAuthentication | 
> NotBoundAuthentication] child element. It seems that the intent was to 
> define a *choice* between KeyBindingAuthentication and 
> NotBoundAuthentication and not a *sequence* where both elements could be 
> omitted, thus provided nothing to authenticate. Comments? -Matt Long