Friday, October 03, 2008

Another angle on OAuth & ID-WSF

A comment from Robert on my doc contrasting the OAuth and ID-WSF authorization models made me think about another way to show their different scope and focus.

Below is a 'typical' ID-WSF flow, with those pieces that OAuth focuses on hilited in grey




As Robert points out, in ID-WSF the identity requestor (the WSC) first 'tries their luck' with an 'unauthorized request' to the identity attribute provider (the WSP). If this request is denied because of the alck of user consent, it's then that the WSP and the WSC engage in an interaction dance in order to get that consent - this set of messages logically identical to the OAuth flow.

OAuth would point to XRDS as providing the discovery component, but it 's not clear to me how to reconcile OAuth's existing static trust model with the possibility of real-time discovery? George?

4 comments:

Praveen said...

Have you looked at the proposed ScalableOAuth Extension ?

http://wiki.oauth.net/ScalableOAuth

in particular the additional authorization flow.

Paul Madsen said...

Hi Praveen, I hadnt looked at it in detail, but I was aware of it. I referred to it in the original doc as

"New functionality for token management (e.g. Renew, revoke, etc) is work in progress"

I'll add a link in the paper (if you agree that this is an accurate description?)

thanks

paul

Praveen said...

Hi Paul,

yes - there is a work in progress to convert this into a real spec (http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html) but at this time the wiki page (http://wiki.oauth.net/ScalableOAuth) is more easy to read and understand.

thanks
Praveen

George Fletcher said...

In addition the standard OAuth flow allows for the SP/WSC to try and get the attribute from the SP in an "un-authorized" state. If the resource requires authorization, the SP sends back a HTTP 401 and requests authorization (section 5.4.2 of the core spec).