Re: xkms:AuthenticationType Schema Definition Issue

Fair enough so.

The policy stuff is just generally hard - how would you handle
a (quite reasonable) policy not to allow registration of 1023
bit rsa keys? I personally don't know how to do that correctly
in general, but maybe there're ways.

In any case, they don't require changes to xkms so far.

Stephen.

Matt Long wrote:

> Hi Stephen,
> 
> I not saying a schema change must be made now, but it is something to 
> note and discuss when another schema change is visible.
> 
> My primary concern right now is how an XKMS service/responder is going 
> to communicate policy to a client. 
> 
> 
> -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 15:23
> 
> 
> 
>     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 <mailto: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 17:00:25 UTC