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 4, 2009, at 9:54 AM, George Fletcher wrote:

> But the need to expose these different endpoints is already a use  
> case. I want my PoCo and ActivityStream endpoints listed in my XRD.  
> How do they get there? Do I (the user) have to add them myself? Does  
> the service that generates the XRD have to provide UI to the user  
> and present them all the choices for what to add? That won't scale.  
> While I believe it's out of scope for XRD 1.0 (as a spec), we need  
> to make sure we don't preclude the ability to define a spec for said  
> provisioning protocol. (In fact, I think Andy and John had started  
> on something like this for XRDS a while back)

Yes, there was some early work on XRDS provisioning... but it stalled  
for (AFAICT) due to time constraints and interest at the time. I agree  
that the users ability to properly manage their XRD Service  
enumerations will be a challenge.  It in fact may prove to be a  
business model all unto itself.

> As for your use case, I'm trying to understand where being able to  
> sign just the "service entry" of the XRD is important? Is this what  
> you meant?
>
> Actors
> User: gffletch
>    personal calendar: google
>    corporate calendar: AOL, LLC
>
> AOL, LLC
>    corporate calendar: outsourced to cal.example.com
>
> Travel service: wanting to access my calendar services
>
> In this case, the Travel service discovers the XRD for gffletch and  
> sees two entries for calendar services. One is listed as personal  
> and the other as corporate. However, Travel services wants to be  
> sure that the corporate calendar entry in the XRD for gffletch is  
> valid for the claimed corporation. So it expects the service entry  
> to be signed by the corporation before it will access or post  
> corporate travel information to the calendar.

Yes, you have captured my intent well.  In essence, the travel service  
may in fact be contractually obligated to ONLY speak to my corporate  
calendar service (likely without users direct consent).  They have no  
real way of fulfilling this obligation without signed entries in any  
scalable fashion.

=peterd

>
>
> Thanks,
> George
>
> Peter Davis wrote:
>>
>> 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.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
> -- 
> Chief Architect                   AIM:  gffletch
> Identity Services                 Work: george.fletcher@corp.aol.com
> AOL LLC                           Home: gffletch@aol.com
> Mobile: +1-703-462-3494           Office: +1-703-265-2544            
> Blog: http://practicalid.blogspot.com
>

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]