Dirk,
On Dec 15, 2008, at 1:56 PM, Dirk Balfanz wrote:
> Hi Pat,
> let me see whether I understand your proposal (from a user
> experience point of view):
> You would like a flow in which a user visits an RP, becomes
> interested in the service the RP provides, and decides to "sign up"
> at the RP. The RP then sends the user to an OP for login, but also
> wants to request access to potentially many OAuth SPs that have the
> user's data.
> So the approval page, at the OP, that the user should see would say
> something like "You're about to log into RP. The RP would like
> access to the following resources: your data X at x.com, your data Y
> at y.com, etc." (where x.com and y.com are not the same as the OP).
> Did I get this right?
not quite.
1. User wants to delegate his authority to a workflow running on a
consumer. He needs to delegate his authority to the workflow to
access various SPs on his behalf. So, yes, he has to authenticate
himself first to consumer. Consumer acts as an RP
2. Consumer now tries to connect to first SP on behalf of the user.
SP needs to turn around and act as an RP and send the Openid+oauth
message. OP should say: "Hey, "consumer X" wants to access resources
Y on SP Z, Are you ok with that?". User can say yea or nay.
3. Workflow continues and accesses as many SP's as needed. Same thing
happens.
I think that it only requires minor change to current message. OP
provides authorization token and OAuth is happy. SP can check back to
OP everytime the workflow knocks at the door to make sure that the
token is still valid.
> If so, then you're right that the current spec on
> step2.googlecode.com doesn't address that use case. For this to
> work, we would have to find a way for the SPs (x.com, y.com in the
> example above) to know that the user really wants the RP to have
> access (both in OAuth, and in the OpenID OAuth extension (which
> assumes OP==SP) the SP knows because the user - which the SP
> authenticates - tells the SP directly).
User openid woudl be passed in the transaction between Consumer and
SP. SP would authenticate the user and verify the claim that Consumer
is making that user will grant access by asking the user (setup mode)
or checking for token validity (immediate mode)
> Can you say more about the actual use cases you have in mind for
> which this would be useful? I'm trying to gauge how important it is
> to solve this problem :-)
Sure. This is to support an OGC Interoperability demonstration with
many organizations including WfMC, NGA, NASA... and many commercial
partners. I can talk more about this offline if you want. I work on
the NASA side. This is a disaster management scenario. This is very
relevant as we are doing a lot of work with Fire Fighters, Red Cross...
Here it is:
There is a major wild fire in California near Airport. Major smoke...
can't see anything...
First responders come to the scene and want to get hyperspectral
imagery to see through the smoke, as well as smoke plume, weather
prediction...
Joe discovers that NASA has a Hyperspectral Imager that can be tasked
(as well as a UAV)....
NASA grants temporary trust to CA Fire Department.
Joe logs in to the Consumer Site (gets authenticated). A workflow is
kicked off on behalf of Joe.
Workflow tries to access the first SP at NASA GSFC to task EO-1
satellite. SP does the dance, user authorizes the workflow to act on
his behalf at SP. SP makes sure this is a real firefighter...and has
proper role using AX....
Eventually data is available, workflow continues with data processing
at various NASA centers (JPL...) and other universities. All other
contextual data is also gathered (weather, DHS data...) and sent back
to firefighters.
NASA had no a-priori knowledge of firefighters. A temporary trust has
to be created.
Eventually Joe may have to revoke his authorization after the
disaster. He does not want to have to go to 10 different sites to do
this.
This is the reader's digest to avoid lengthy email (for which I
obviously failed)
Pat.
