RE: [xri] This is a job for... OAuth...

Nika,

You may have emailed this to the wrong TC ;-)

What I mean is, cross-domain authorization is one of the core problems for which XDI is being developed. XDI is based entirely on XRIs because cross-domain authorization requires cross-domain identifiers (cross-references) and that as you know is one of the core features of XRI syntax.

XDI as a protocol can be bound to HTTP, HTTPS, or any other transport protocol that can exchange XDI documents (instances of the XDI RDF graph model – see http://wiki.oasis-open.org/xdi/XdiRdfModel). This is the wrong list to discuss it in detail, but if you are interested in exploring how XDI might work for your solution, consider joining the XDI TC, even as a non-voting member, so you access the list there.

Best,

=Drummond

From: John Bradley [mailto:jbradley@mac.com]
Sent: Saturday, September 20, 2008 12:06 PM
To: njones@ouno.com
Cc: OASIS XRI TC
Subject: Re: [xri] This is a job for... OAuth...

It looks like it is a reply to something.

However if it's not, I will do my best to decipher it.

An Oauth permissioning step can be preformed by the user so the FTP client has an access token in advance.

The Oauth protected service endpoint can redirect the client to a URI where it could get a token in some manner. The credentials used for that are up two the two parties and can be a PKI based or some other thing.

If the user permissions the Oauth endpoint in advance. the user doesn't need to be involved in the token interaction.

This is sort of what the ID-WSF interaction and discovery services are about.

You may want to look there for a "better designed" oAuth.

=jbradley

On 20-Sep-08, at 11:51 AM, njones@ouno.com wrote:

John:

No, I'm in a situation where I need to authorize an intermediary access to a resource after discovered by XRI. While the initiating party is not on HTTP...

Hummm... Are there any resources on the web about how the i-name contact page is supposed to be implemented? That may hold some clues to my problem. I think.

Nika

From: John Bradley <jbradley@mac.com>
Date: Sat, 20 Sep 2008 11:40:28 -0700
To: Nika Jones<njones@ouno.com>
CC: OASIS XRI TC<xri@lists.oasis-open.org>
Subject: Re: [xri] This is a job for... OAuth...

Nika,

I think there must be some other part of this email?

=jbradley

On 20-Sep-08, at 11:29 AM, Nika Jones wrote:

Well, I'd think so, but I'm not sure it will work, thus I have the following problem:

Say, I would like for my client to upload a file via FTP to my sever. They have a simple headless terminal application of, "their own design," which handles the file upload, so --no browser.

Within the file they upload I've embedded an XRI identifier, A batch job runs on the server the file was uploaded to, grabbing the XRI identifier from the file and does a proxy resolution for the XRI.

Now here's the catch, the service resolved from the proxy resolution should return a private resource. So, this is something that only should be returned if the user who uploaded the file has authorization.

Normally one would use OAuth in this situation, right, to assign rights to a third-party, right? However because FTP was used as the first leg, there seems to be no way manage the relationship between all parties (using redirects and all of the niceties of HTTP).

Has any one dealt with a problem such as this before? If so any ideas on a possible solution? Another way to phrase the question is; if you have a "protected" resource managed by XRDS discovery, what are best practices to protect that resource?

Regards,

Nika

---------------------------------------------------------------------
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

xri message