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 (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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]