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

Sent: Saturday, September 20, 2008
12:06 PM

To: 

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

Date: Sat, 20 Sep 2008 11:40:28
-0700

To: Nika Jones<>

CC: OASIS XRI TC<>

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