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] xml dsig profile


On Mar 3, 2009, at 5:00 PM, Brian Eaton wrote:

> For the record, I agree that if we want to start having multiple
> objects in a single XML object with different signatures, we should
> use XML DSIG and be done with it.

agreed.

> I don't think that's a real use case for XRDs.

disagree.  while we have not discussed this as yet in the TC, there  
will ultimately (IMHO) be a need to provision portions of an XRD into  
an end user XRD instance.  for example:

- user wants to add google calendar to their XRD to allow others to  
subscribe to it
	- user instructs google to add their calendar service endpoint to  
their XRD
- user wants to add a corporate calendar to their XRD to allow some to  
subscribe to free/busy data
	- user instructs their companies exchange server to add their  
calendar service endpoint to their XRD

relying parties to these calendar services may want to authenticate  
the service endpoint entry as belonging to MyCompany (especially if  
the calendar service is outsources to a third party).

one could construct all sorts of use cases for other services.  so i  
think these are valid, but as i've said, we presently have no protocol  
to push these service endpoints into an XRD.

=peterd

>
>
> On Tue, Mar 3, 2009 at 12:32 PM,  =JeffH  <Jeff.Hodges@kingsmountain.com 
> > wrote:
>> Below's Scott's succinct summary of our rationale wrt the "SAMLv2.0  
>> HTTP POST
>> 'SimpleSign' Binding".
>>
>> =JeffH
>> ------
>> Subject: RE: [xri] xml dsig profile
>> From: "Scott Cantor" <cantor.2@osu.edu>
>> Date: Tue, 3 Mar 2009 11:39:50 -0500 (08:39 PST)
>> To: "'Peter Davis'" <peter.davis@neustar.biz>,
>>        "'Jeff Hodges'" <Jeff.Hodges@KingsMountain.com>
>>
>> Peter Davis wrote on 2009-03-03:
>>> the XRI TC is looking at variations of the simple-sign work done for
>>> the SSTC, and I have suggested that we should not introduce a new
>>> model unless we are very compelled to do so.
>>
>> Unless you're working with a messaging model in which you're just  
>> trying to
>> sign essentially everything you're expressing in XML, I doubt that  
>> it's a
>> good model. Something that has to be composed of different pieces and
>> potentially include signed objects and unsigned objects within the  
>> same
>> document, which strikes me as a need for things like XRDS, probably  
>> needs to
>> use XML Signature.
>>
>>> Can you provide any background wrt the model you choose
>>> (optimizations, work-arounds, deployment experiences) that i can
>>> reflect back to the XRI TC?
>>
>> I have no deployment experience with it. Far as I know, only AOL  
>> has used it
>> a bit. Generally when people reject XML Signature, they've also  
>> rejected XML
>> to begin with, and being able to solve the signing problem just  
>> changes the
>> excuse they use.
>>
>> The model we chose was really to address two issues:
>>
>> - avoiding c14n as currently defined (note even for the "simple"  
>> spec, we
>> had to go around a few times to come up with a workable signing  
>> model, so
>> c14n is always a problem, even when you deal with data as a blob)
>>
>> - expressing the signature without using the ds:Signature element,  
>> because
>> there's no way to build a signature Reference to a set of form  
>> elements in
>> an HTML page
>>
>> The goal we had was to sign messages bound to HTML forms, so that  
>> didn't
>> leave much in the way of existing options. I've raised that point  
>> with the
>> W3C working group. I think it would be better if we could build  
>> references
>> to parts of IETF protocol messages such as HTTP but still reuse the
>> ds:Signature element and reference model. At the moment, that's  
>> pretty
>> impossible to do.
>>
>> We weren't trying to solve the more general signing problem OAuth  
>> took on,
>> but clearly one could reuse that piece of OAuth (which shouldn't be  
>> part of
>> OAuth to begin with) to handle this kind of signing.
>>
>> In terms of implementing this, you need essentially all the same  
>> crypto
>> dependencies you would need for XML Signature, and you end up  
>> calling into
>> the raw PKCS1 signing code that the signature library would be using.
>>
>> We reused the ds:KeyInfo structure so that key material expression  
>> was
>> consistent between XML and Simple signing in SAML.
>>
>> My impression from my participation in the W3C group right now is  
>> that they
>> "get" the problem. Nobody is happy with c14n as currently defined,  
>> and
>> there's a serious proposal [1] right now to essentially start over  
>> with a
>> simpler spec. If that happens, I believe it would be a mistake to  
>> continue
>> with these workarounds.
>>
>> -- Scott
>>
>> [1] http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/
>>
>> ---
>> end
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>

Peter Davis: NeuStar, Inc.
Director & Distinguished Member of the Technical Staff
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ 
  [X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for  
the use of the recipient(s) named above and may contain confidential  
and/or privileged information. If you are not the intended recipient  
you have received this e-mail message in error and any review,  
dissemination, distribution, or copying of this message is strictly  
prohibited. If you have received this communication in error, please  
notify us immediately and delete the original message.




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