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


I'm no expert in signing but I agree with Brian on the overall principal
here: the XRD is not the place to prove whether the XRD author (which is
frequently but not always a "user") does or does not have a relationship
with a service provider. Use an OAuth token or XDI link contract to do that.

The XRD is simply the place for the XRD author to make the assertion that
they have the relationship with the service provider, and the signature is
there to let a consuming application verify this assertion (and perhaps key
metadata regarding the assertion, such as the Subject).

For really wide deployment, it's essential that XRD architecture be as
simple as possible.

=Drummond 

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Wednesday, March 04, 2009 9:45 AM
> To: George Fletcher
> Cc: Peter Davis; =JeffH; xri@lists.oasis-open.org
> Subject: Re: [xri] xml dsig profile
> 
> On Wed, Mar 4, 2009 at 6:54 AM, George Fletcher
> <george.fletcher@corp.aol.com> 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.
> 
> That challenge needs to be addressed independent of any questions
> about XML DSIG vs Simple Sign vs Magic Security Dust.
> 
> Once we figure out the flows involved in managing XRDs, I think we'll
> end up at a point where each XRD for each user has either no signature
> (for use cases where security is not critical) or one signature.
> 
> The single signature case would work as follows:
> 
> Actors: user, XRD host, third party
> 
> 1) Third party gets permission to modify the XRD for the user.  That
> could be via an OAuth approval, or something out of band.
> 
> 2) Third party sends a message to XRD host asking to add a service entry.
> 
> 3) XRD host adds the entry, resigns the XRD for the user.
> 
> One key is all that's necessary, because the XRD for the user is *only
> making statements about the user*.  If you want authoritative data
> about the service, you need to go ask the service for that.
> 
> So, yes, I see a need for service discovery and publication, no, I
> don't see a need for a single XRD to have multiple entries signed by
> different entities.
> 
> ---------------------------------------------------------------------
> 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




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