OAuth 2.0 endpoint for PDS

[Markus Sabadello]

Hello,

I'm trying to build an OAuth 2.0 endpoint on top of the PDS..
This library looks useful: http://bitbucket.org/smartproject/oauth-2.0/wiki/Home
Apparently it's brand new, and made by our good UMA friends.

This should enable a relying party web site to authenticate a user and obtain personal data from their PDS.

Currently trying to figure out how exactly OAuth 2.0 relates to OpenID Connect, and how much traction OpenID Connect has.
Maybe we want a separate OpenID Connect endpoint, or only an OpenID Connect endpoint, and no OAuth 2.0 endpoint.
Not sure.

Markus

[Joseph Boyle]

OpenID Connect is on top of OAuth 2.0 - my first instinct would be to use the highest level available library if it has functionality we want.

However I don't know of an existing OpenID Connect implementation. The mailing list http://lists.openid.net/pipermail/openid-specs-connect/ seems to be still discussing features and lining up major companies. So you might want to join this group. Posting to the list requires signing an OIDF Contribution Agreement.

If you wind up having to implement functionality similar to OpenID Connect anyway, you could also try to conform to their spec (or what is known of it now) and have an OpenID Connect implementation.

[Markus Sabadello]

It seems a generic OAuth 2.0 endpoint makes sense anyway, so I'm focusing on that now.
With this it becomes possible to run arbitrary XDI queries against a user's PDS, provided permission is given.
Need to consider security of course and how this relates to link contracts. Theoretically, someone could delete everything in your PDS :D

OpenID Connect is for actually signing in to a relying party, rather than just giving it access to something.
Guess we can support that too at a later time.

Funny how each iteration of these standards claims to be simpler than the one before.
Just like every Windows version is faster than the previous one.

Markus

[Joseph Boyle]

Right, I wasn't arguing against an OAuth 2.0 endpoint, I actually meant to say it would be a good step even if we eventually wind up using more protocol layers on top of it. I think you're doing the right thing. Would like to look at code with you.

[Markus Sabadello]

Will check in a first version later today or tomorrow.

In the meantime I started a few conversations with the developers of that library:
http://groups.google.com/group/oauth-leeloo-dev

I think I found a bug.

Markus

[Joe Johnston]

Go Markus, go!

OAuth permissions should determine the link contract. At least that's
my quick $0.02.

Suggested user flow ...

1) User goes to pds-application-example.com and clicks login (for this
example, let's assume an active client provided the PDS provider OAuth
endpoint)

2) OAuth browser window pops up, prompting user to login to his/her
PDS provider; user logs in to provider

3) User is presented with requested OAuth permissions; e.g. read+write
to social graph, read identity graph

4) User approves permissions request and is redirected back to the
app; app is given OAuth token

5) App sends a get link contract request to PDS and includes the OAuth
token; link contract is returned with the permissions selected by the
user during OAuth

6) App sends XDI messages and OAuth token to PDS; PDS check OAuth
token for validity (no permissions enforcement yet) and then passes
the message on to the XDI Messaging Engine to enforce the link
contract

Revoking the OAuth token should also revoke the link contract and vice versa.

Do you think this flow is correct?

Cheers,
Joe

[Markus Sabadello]

Hmm yes that's along my link of thinking, we should discuss this on the phone maybe on Monday or Tuesday.

Anyway, see some quick thoughts inline.

On Sat, Oct 2, 2010 at 9:10 PM, Joe Johnston <joejoh...@gmail.com> wrote:

Go Markus, go!

OAuth permissions should determine the link contract.  At least that's
my quick $0.02.

Suggested user flow ...

1) User goes to pds-application-example.com and clicks login (for this
example, let's assume an active client provided the PDS provider OAuth
endpoint)

[Markus] Not quite sure what the button you click on would say.. If it says "Login to this site", then I believe it would be an OpenID Connect flow, whereas if it says "Login to your PDS so that this site can read/write some data to/from it", then it would be a pure OAuth 2.0 thing. I think I'm currently working on the second case. But I might be wrong, still trying to understand the real differences between the two.

Haven't spent time at all yet thinking about how an active client fits into the PDS idea, need to discuss that too. Paul has a good presentation on this.

2) OAuth browser window pops up, prompting user to login to his/her
PDS provider; user logs in to provider

[Markus] No window popping up in what I'm currently doing, but yes that would work pretty much the same way I think...

3) User is presented with requested OAuth permissions; e.g. read+write
to social graph, read identity graph

[Markus] Yes.. I am thinking, the OAuth 2.0 endpoint should be generic enough to allow any arbitrary XDI message to the XDI graph, but the OAuth 2.0 endpoint should be smart enough to "interpret" it and tell the user what it means. Or display a big warning sign if it doesn't understand it. Or maybe we should not allow so much freedom and only allow a few pre-defined XDI patterns. Or maybe that should depend on the OAuth 2.0 client ID, i.e. some privileged clients can do what they want, while others can only access basic stuff.

4) User approves permissions request and is redirected back to the
app; app is given OAuth token

[Markus] Yes. If I understand OAuth 2.0 correctly, the app could either get the access token directly, or it could get an "authorization code", which it then uses to get the access token.
 

5) App sends a get link contract request to PDS and includes the OAuth
token; link contract is returned with the permissions selected by the
user during OAuth

[Markus] Not sure how link contracts fit into all this exactly. I don't think the client needs the link contract, it just has to sit inside the PDS so that access with the OAuth 2.0 access token is possible.

In OAuth terms, the XDI endpoint is the "protected resource", and you use your OAuth 2.0 access token to authenticate to it.
 

6) App sends XDI messages and OAuth token to PDS; PDS check OAuth
token for validity (no permissions enforcement yet) and then passes
the message on to the XDI Messaging Engine to enforce the link
contract

[Markus] Yes, exactly.

Revoking the OAuth token should also revoke the link contract and vice versa.

Do you think this flow is correct?

[Markus] I'm a bit new to OAuth 2.0. Maybe let's do a call early next week specifically on this topic?

Markus
 

[Michael Schwartz]

Would it be helpful to differentiate between inbound and outbound OAuth
functionality? The idea of giving an application access to my PDS seems
much more challenging than using OAuth to send my content to a relying
party.

And if we are going to allow an application to write to a PDS, should the
write permission be limited to a specific context? By limiting the scope,
would that be an expedient solution to limit the security risk?

- Mike

--------------------------------------------------------------------------------------

Michael Schwartz
Gluu
Founder, CEO
mi...@gluu.org
https://www.gluu.org
+1 646-810-8761

[Markus Sabadello]

From an OAuth 2.0 protocol flow perspective, there's no difference between "inbound" and "outbound", or between "read" and "write".

In all cases, you "give an application access to your PDS".

What kind of operations in what context we want to allow for what applications under what configuration, those are the things we need to figure out and align with link contract functionality..

For now, I'll work on an OAuth 2.0 endpoint that allows any XDI operation provided the user gives permission.

Markus

[Joe Johnston]

Sounds great Markus. I'm available to chat on Monday morning.

Cheers,
Joe

[Markus Sabadello]

Okay I'm putting together this page:
http://projectnori.pbworks.com/PDS-Weekly-Retreat-Oct-4-2010

How about 11am Pacific Time tomorrow? Does that work for everyone? Mike said it has to be after 12pm EST.
Maybe I can also invite the UMA folks who are writing the library I'm using.

Markus

[Joe Johnston]

11AM PDT works for me.

Cheers,
Joe

On Sun, Oct 3, 2010 at 10:23 AM, Markus Sabadello

[Markus Sabadello]

Here's something to watch before the call:
http://vimeo.com/15504854

Markus