OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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