[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Removing ds elements from schema
OK. You all were working through my night here :-) So the conclusion is to drop <extensions> and recommend to use only one signature, is that right? =nat Will Norris wrote: > Given that many, if not most, of the people who were in favor of the > <Extensions> element have expressed favor toward this approach, I'm > going to go ahead and start reworking the text. I'm certainly not > considering this matter closed, but I don't want to delay getting > started on the work for too long. So if people have further comments > the please, by all means, add them. > > -will > > > On Sep 8, 2009, at 10:43 AM, Eran Hammer-Lahav wrote: > >> 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 >> >> >> --------------------------------------------------------------------- >> 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 > > > --------------------------------------------------------------------- > 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]