Re: http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html

[David Recordon]

Adding the step2 mailing list to this thread.

Thanks,
--David

On Dec 13, 2008, at 1:56 PM, Pat Cappelaere wrote:

> Gentlemen,
>
> As part of an interoperability effort sponsored by the Open
> GeoSpatial Consortium (OGC), the Workflow Management Coalition and a
> few other partners including myself have signed up to address the
> issue of RESTful workflows accessing restricted web services across
> many organizations.
>
> This scenario presents many challenges due to the number of services
> that could potentially be accessed by the workflows on behalf of the
> users.
>
> Workflow Chaining Services (WfCS) are themselves nothing more than
> black-box web services as far as the user is concerned.
>
> Token Management from a user perspective and service provider (SP)
> is also an issue. We want to make it as simple as possible for the
> user to grant/revoke identity delegation and as easy as possible for
> those providers to implement the protocol in a uniform and
> consistent manner.
>
> OAuth has been implemented without OpenID as an assumption. This
> was a great idea.
>
> If OpenID is now a reality for our community, how can we leverage it
> to provide a consistent user experience? The user is already
> familiar with the concept of granting "sites" usage of his identity
> and access (or not) to his profile info.
> The user can also manage these grants from his OpenID account, get
> notifications when "sites" request access....
>
> There seem to be a small step to make to integrate OAuth within the
> existing infrastructure that is already made available by the
> exisiting openID providers such as myopenid.com and myvidoop.com.
>
> I have looked at the proposed extension (http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
> ) but feel that it may fall short from this expectation (but could
> be wrong). This is certainly a good first step.
>
> Instead of asking for an access token from a user out of context
> (who is the consumer, who is the provider, what is the requested
> access realm or resource), why can't we make this part of the request?
>
> The user could respond with yea/nay and even make this semi-
> permanent until revoked right from that same account. The service
> provider could keep checking in with the immediate mode. This makes
> it very simple for the SP (which already supports openid as an RP).
> Service providers are seldom OPs in our case.
>
> This makes is very consistent for the user. S/he does not have to
> go to X number of sites and manage access in various manners.
>
> I would appreciate your feedback.
>
> Thanks,
>
> Pat.
>

[David Recordon]

[Dirk Balfanz]

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?

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

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

Dirk.

On Sat, Dec 13, 2008 at 7:55 AM, David Recordon <drec...@sixapart.com> wrote:

Adding the step2 mailing list to this thread.

Thanks,
--David

On Dec 13, 2008, at 1:56 PM, Pat Cappelaere wrote:

Gentlemen,

As part of an interoperability effort sponsored by the Open GeoSpatial Consortium (OGC), the Workflow Management Coalition and a few other partners including myself have signed up to address the issue of RESTful workflows accessing restricted web services across many organizations.

This scenario presents many challenges due to the number of services that could potentially be accessed by the workflows on behalf of the users.

Workflow Chaining Services (WfCS) are themselves nothing more than black-box web services as far as the user is concerned.

Token Management from a user perspective and service provider (SP) is also an issue.  We want to make it as simple as possible for the user to grant/revoke identity delegation and as easy as possible for those providers to implement the protocol in a uniform and consistent manner.

OAuth has been implemented without OpenID as an assumption.  This was a great idea.

If OpenID is now a reality for our community, how can we leverage it to provide a consistent user experience?  The user is already familiar with the concept of granting "sites" usage of his identity and access (or not) to his profile info.
The user can also manage these grants from his OpenID account, get notifications when "sites" request access....

There seem to be a small step to make to integrate OAuth within the existing infrastructure that is already made available by the exisiting openID providers such as myopenid.com and myvidoop.com.

I have looked at the proposed extension (http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html) but feel that it may fall short from this expectation (but could be wrong).  This is certainly a good first step.

Instead of asking for an access token from a user out of context (who is the consumer, who is the provider, what is the requested access realm or resource), why can't we make this part of the request?

The user could respond with yea/nay and even make this semi-permanent until revoked right from that same account.  The service provider could keep checking in with the immediate mode.  This makes it very simple for the SP (which already supports openid as an RP).  Service providers are seldom OPs in our case.

[Pat Cappelaere]

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.