[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] xml dsig profile
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.com
AOL LLC Home: gffletch@aol.com
Mobile: +1-703-462-3494
Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]