RE: [xri] Removing ds elements from schema (was: OpenID Delegatingrelationship in XRD)

[Eran Hammer-Lahav <eran@hueniverse.com>]

I completely agree.

EHL

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Tuesday, September 08, 2009 10:00 AM
> To: XRI TC
> Subject: Re: [xri] Removing ds elements from schema (was: OpenID
> Delegating relationship in XRD)
> 
> 
> On Sep 8, 2009, at 9:52 AM, Will Norris wrote:
> 
> > On Sep 8, 2009, at 9:46 AM, John Bradley wrote:
> >
> >> I can live without the extension wrapper if we have a better way.
> >>
> >> I think recommending having the signature at the top for streaming
> >> applications is sufficient.
> >>
> >> I don't think it makes any real difference to most parsers.
> >>
> >> The best way to limit it to one is the question.
> >
> > Well, we would still have the XRD Signature section in the core
> > spec, so we could state that there can be only one signature.  We
> > wouldn't be enforcing it at the schema level, but I think that's
> > okay.  We're already placing a number of restrictions on the
> > Signature itself (specifically, reference and transformation) that
> > weren't schema-enforced, so I don't see adding cardinality to that
> > list as being a huge deal.  It's not as clean as one might like, but
> > doable.
> 
> Of course now that I think about it, nothing prevents people from
> having multiple signatures using the current schema.  We state only
> that extension elements must not use the XRD namespace, but say
> nothing of the DSig namespace.
> 
> I'm thinking that the farthest we should go (if at all) is to
> *recommend* that a only a single signature be used, because many
> (most?) consumers will not be able to properly handle multiple
> signatures.  The common signing use case is going to be a single
> signature, so hopefully we won't have to worry about this too much.
> And if someone is feeling industrious and wants to add multiple
> signatures, I'm not sure that we should necessarily try and stop
> that.  They just need to be aware of the potential complications
> involved.
> 
> -will
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php