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:]
>> 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
>
