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 16:29:08 +0100
Message-ID: <42EA4B44.9020000@cs.tcd.ie>
To: Matt Long <mlong@mvsquared.net>
Cc: www-xkms@w3.org


Hi Matt,

I guess I don't understand the concern with this, other than
it being possible to save a few bytes (but, hey, this is xml!).

I do see that being able to omit the Authentication element
entirely would be more perfect, but what I don't see is the
practical benefit.

Put another way, I don't see sufficient benefit to warrant
a schema change now. For the future, I could see us allowing
omission of the Authentication element and also allowing
unbounded (much as I dislike that) for the two types of
authentication information.

Stephen.

Matt Long wrote:

> Hi Stephen,
> 
> If the AuthenticationType complexType MAY contain no child elements (as 
> per current schema), it seems to me that one would want to omit the 
> xkms:Authentication element, which under current schema cannot be done.  
> Reason being that the Authentication element (with no child elements) 
> has no discrete context in the request unless it contains child elements. 
> 
> My concerns are shifting towards communicating policy to a client from 
> the prespective of the server/responder.
> 
> Thx,
> 
> -Matt
> 
> 
> 
>     --------- Original Message --------
>     From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
>     To: "Matt Long" <mlong@mvsquared.net>
>     Cc: www-xkms@w3.org
>     Subject: Re: xkms:AuthenticationType Schema Definition Issue
>     Date: 07/29/05 13:25
> 
> 
> 
>     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 15:23:33 UTC

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