Re: [xri] Removing ds elements from schema (was: OpenID Delegating relationship in XRD)

[Will Norris <will@willnorris.com>]

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
>