| Andy did propose an XRDS Provisioning Protocol (XRDSPP) two years ago, however like most of our ideas we were three years ahead of the market.
At that time openID OPs were providing a single template for all there users if they were providing an XRDS at all. We also didn't have open Social, oAuth or other services to provision.
We will eventually need some provisioning service.
I don't necessarily see that that requires individually signed links.
I can see the links pointing to XRD that are signed by the service provider that are explicit about the localID they are authoritative for.
That was what we envisioned ref being used for in XRD 2.0.
Now that redirect is the default behavior in following links, the only real difference is that you need to be explicit about the LocalID in the target XRD.
John B. On 4-Mar-09, at 6: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) 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. 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.comAOL LLC Home: gffletch@aol.comMobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com--------------------------------------------------------------------- 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
|