Good points. Couple of thoughts: a) This looks like a Y OAuth or transitive OAuth or even federated SPs. b) Would this be solved by a scope artifact, which has two URLs Application1 and Application 2 (with associated restrictions et al, as required). Then the token can be used for both. c) Agreed on not replicating the user database. d) I assume even in this case user enters credentials only once. The key question is how do we propagate the trust fabric, securely. e) In short, I think there is no need for anything more in the specification; a usage pattern would suffice.
Cheers <k/> |-----Original Message----- |From: [email protected] [mailto:[email protected]] On Behalf |Of J Kwan |Sent: Tuesday, February 03, 2009 2:42 AM |To: OAuth |Subject: [oauth] Re: Does OAuth support a 4 legged scenario? | | |I'm also interested in implementing something of similar structure as |well, though I'm not quite sure if it's actually feasible or can be |implemented with oauth at all. I'm actually quite conflicted on the |idea. |What I can see is, in this scenario, application 1 most likely has its |own set of user accounts that mirror the user accounts on the service |provider. That said, application 1's user accounts probably shouldn't |be directly linked or tightly coupled to the user accounts in the |service providers, otherwise, it seems to defeat the purpose of using |oauth to hide the actual user accounts information from the consumer. |If the user accounts are separated from the service provider (or at |least treated as such), then application 1 itself probably has to |become a service provider itself to allow application 2 to connect to |it, which means application 2 has to establish 2 different oauth |connections to both the original service provider and to application |1... |That leaves the problem of how to connect application 1 and the |service provider via application 2. | |It'd be nice if OAuth can be specified to solve such problem, |something like for a consumer to connect to a distributed set of |service providers, and the service providers can inter-communicate |based on a single oauth connection. | |Anyone else got other ideas? | |On Jan 23, 6:28 am, nate_fish <[email protected]> wrote: |> Does OAuth support a 4 legged scenario? |> |> In this four legged scenario, there is a shared service |provider,application1 which holds the consumer data andapplication2 |which is |> trying to access data onapplication1. How would this scenario look |> to the user? |> |> My initial thought is thatapplication2 uses the OAuth 3 legged |> scenario to get access to the users data with Service Provider. They |> then use unique account id from service provider to identify user |withapplication1 and get authorization fromapplication1. |> |> Anyone solve for this yet or have any recommendations? | | --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
