W3C home > Mailing lists > Public > www-xkms@w3.org > July 2005

Re: xkms:AuthenticationType Schema Definition Issue

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 29 Jul 2005 14:31:48 +0100
Message-ID: <42EA2FC4.8060009@cs.tcd.ie>
To: Matt Long <mlong@mvsquared.net>
Cc: www-xkms@w3.org


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
Received on Friday, 29 July 2005 13:26:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:44 UTC