[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Removing ds elements from schema (was: OpenID Delegatingrelationship in XRD)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]